Re: Tecnicas para mejora de eficiencia en consultas

Arturo Munive [pgsql-es-ayuda] escribió:
> Hola:
> hace un tiempo lei un articulo (para Oracle) que entre otras cosas decía:
> -------------------
> Es frecuente el uso de sentencias en las que se pregunta por un campo nulo,
> para actualizarlo a continuación. Si la tabla es
> muy grande y van a recuperarse pocos registros, interesa que ese campo
> tenga inicialmente un valor por defecto (no nulo), y
> se pregunte luego por ese valor. Por ejemplo, una tabla CLIENTES con un
> campo TELEFONO. Este campo se deja
> inicialmente con NULL y se ejecutan sentencias del tipo
>
> select * from clientes where telefono is null;
>
> Esta sentencia siempre hara un recorrido secuencial
>
> -------------------
>
> es esto cierto para PostgreSQL tambien?

Si.

> cito:
> ---------------------------
> La clave del buen rendimiento de una operación NESTED LOOPS es el orden en
> que se realiza el join de las tablas. El
> número de repeticiones del bucle es el producto del número de registros
> resultante de la primera tabla por el número de
> registros de la segunda tabla a los que se accede después. Si se añaden
> más tablas en el join, la elección de la primera tabla
> es aún más crítica. Lo conveniente es minimizar el número de registros
> leídos en los primeros pasos del bucle.
> Consideremos un ejemplo. Tenemos una sentencia en la que aparecen 4 tablas
> (A, B, C y D), todas ellas del mismo tamaño,
> con las siguientes cláusulas FROM y WHERE:

Esto no aplica; el optimizador reordena los joins segun le parece
conveniente. (Hay algunas cosas que puedes ajustar para modificar este
comportamiento pero casi nunca es necesario)

> imaginense que tengo un indice en cada uno de esos campo
> si index_a es mas selectivo que index_b
> entonces hay alguna diferencia si ejecuto:
>
> campo_a = un_valor AND cambo_b = otro_valor
>
> o sie ejecuto
>
> cambo_b = otro_valor AND campo_a = un_valor

No. Si ambos indices son suficientemente selectivos, usara ambos en el
orden mas conveniente.

Mis respuestas asumen una version razonablemente moderna (i.e. 8.1 como
minimo)

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support