From: | Arturo Munive <arturomunive(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Postgresql <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: Tecnicas para mejora de eficiencia en consultas |
Date: | 2007-09-05 23:49:51 |
Message-ID: | 46DF409F.4010100@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
Alvaro Herrera escribió:
> 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)
Ok. gracias.
Una cosa mas no creen que deberiamos hacer una base de datos con tablas
relacionadas de las maneras en que mas comun se presentan y poblarlas
con datos (los suficientes comp para hacer nuestras pruebas) y claro la
pondríamos a disposicion de todos.
Oh mi idea es muy descabellada?? pondriamos solo los scripts.
asi cuando llegue una consulta cualquiera de nosotros podria reproducir
rapidamente el problema y apoyarnos entre todos no creen, es solo una
idea la iré madurando
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2007-09-05 23:50:40 | Re: consulta sobre creacion de triggers en postgres |
Previous Message | Roberto Andrade Fonseca | 2007-09-05 23:34:20 | Re: Tecnicas para mejora de eficiencia en consultas |