Tienes razón, en parte, porque si el servidor es linux y tienes más de una cpu, cuando lanzas la consulta ocupa una de las cpu, pero las demás siguen libres para seguir antendiendo a los restantes usuarios.
He hecho una prueba con una pequeñita, poco más 500 Mb. y efectivamente el primer select lo recorre entero "natural", aunque de todas formas, el tiempo requerido ha sido 1 segundo.
Cita:
Prepare time: 00:00:00.
Field #01: .CLIENTE Alias:CLIENTE Type:INTEGER
Field #02: .TOTAL Alias:TOTAL Type: DOUBLE PRECISION
PLAN (TBCABECERASFACTURASVENTAS NATURAL)
PLAN (TBCABECERASFACTURASVENTAS ORDER INDCABFACVEN_CLIENTECODIGO)
Executing...
Done.
317488 fetches, 0 marks, 0 reads, 0 writes.
0 inserts, 0 updates, 0 deletes, 62675 index, 62631 seq.
Delta memory: 1184 bytes.
Execute time: 00:00:01.
Script execution finished.
|
Con otra tabla que tiene más registros (1279329), 2 segundos:
Cita:
Prepare time: 00:00:00.
Field #01: .CODIGOPEDIDO Alias:CODIGOPEDIDO Type:INTEGER
Field #02: .PRECIO Alias:PRECIO Type: DOUBLE PRECISION
PLAN (TBLINEASALBARANESVENTAS NATURAL)
PLAN (TBLINEASALBARANESVENTAS ORDER RDB$FOREIGN3)
Executing...
Done.
1279329 fetches, 0 marks, 10697 reads, 0 writes.
0 inserts, 0 updates, 0 deletes, 253736 index, 253720 seq.
Delta memory: 1192 bytes.
Execute time: 00:00:02.
Script execution finished.
|
La prueba la he hecho en mi ordenador personal, ubuntu 8.04 con firebird 2.1 y un AMD athlon 64 x2 dual 4600 con 2 Gb