En una tabla con las columnas a, b, c, d, e, f, g, h, i, j, k obtengo:
select * from misty order by a limit 25;
Time: 302.068 msY:
select c,b,j,k,a,d,i,g,f,e,h from misty order by a limit 25;
Time: 1258.451 ms¿Hay alguna manera de hacer la selección por columna tan rápido?
Actualizar:
No hay índice en una tabla, uno recién creado
Aquí está el EXPLICAR ANÁLISIS, no parece demasiado útil:
explain analyze select * from misty order by a limit 25;
Limit (cost=43994.40..43994.46 rows=25 width=190) (actual time=404.958..404.971 rows=25 loops=1)
-> Sort (cost=43994.40..45731.11 rows=694686 width=190) (actual time=404.957..404.963 rows=25 loops=1)
Sort Key: a
Sort Method: top-N heapsort Memory: 28kB
-> Seq Scan on misty (cost=0.00..24390.86 rows=694686 width=190) (actual time=0.013..170.945 rows=694686 loops=1)
Total runtime: 405.019 ms
(6 rows)Y:
explain analyze select c,b,j,k,a,d,i,g,f,e,h from misty order by a limit 25;
Limit (cost=43994.40..43994.46 rows=25 width=190) (actual time=1371.735..1371.745 rows=25 loops=1)
-> Sort (cost=43994.40..45731.11 rows=694686 width=190) (actual time=1371.733..1371.736 rows=25 loops=1)
Sort Key: a
Sort Method: top-N heapsort Memory: 28kB
-> Seq Scan on misty (cost=0.00..24390.86 rows=694686 width=190) (actual time=0.015..516.355 rows=694686 loops=1)
Total runtime: 1371.797 ms
(6 rows)
postgresql
postgresql-9.2
Evgeny
fuente
fuente
select *caso y aproximadamente 2.2 segundos para la selección con columnas enumeradas en un orden diferente .select *.Respuestas:
Esto fue publicado en la lista de correo pgsql-hackers y traté de responder brevemente allí. Parece que si la lista de destino (columnas especificadas) coincide exactamente con el descriptor de tupla de la relación, es decir, tanto en número de columnas como en orden, entonces el escaneo subyacente puede devolver una tupla que es directamente consumible por el nodo Ordenar adjunto. Por otro lado, si la lista de destino no coincide (ya sea en orden o el número de columnas especificadas), el escaneo devuelve una forma de las tuplas que requiere el paso de preparación de datos de Sort para realizar un trabajo adicional (convertir de un formato de tupla interno a el formato directamente consumible por el código de clasificación).
Por cierto, '*' se transforma internamente en una lista que (intuitivamente) coincide con el descriptor de tupla de la relación.
EDITAR: Si observa los últimos tiempos reales de la Exploración de Seq de EXPLAIN ANALYZE, puede ver que es más que los anteriores. Eso sucedió porque la exploración realizó un paso adicional de proyección (es decir, convertir la tupla de montón en un formato de valores internos [], nulos []). Y como eso sucedió, el nodo de clasificación superior tuvo que hacer un trabajo adicional en su inicialización de datos, el de convertirlo nuevamente al formato de tupla que el paso de clasificación real comprende. Eso es evidente por el costo de inicio de Sort. Eso no sucede en el primer caso. Es decir, tanto el escaneo devuelve la tupla como está y el paso de inicialización del tipo simplemente lo copia.
fuente