RE: alter column x set statistics = n, pg_log, query planner

Comentarios más abajo

-----Mensaje original-----
De: pgsql-es-ayuda-owner(at)postgresql(dot)org
[mailto:pgsql-es-ayuda-owner(at)postgresql(dot)org]En nombre de Alvaro Herrera
Enviado el: lunes, 29 de agosto de 2005 23:56
Para: Dario
CC: pgsql-es-ayuda(at)postgresql(dot)org
Asunto: Re: [pgsql-es-ayuda] alter column x set statistics = n, pg_log,
query planner

>> - Si es si ¿Puedo hacer que el query planner decida resolver por mayor
>> selectividad (aunque sea el último left join de una consulta) o voy a
tener
>> que resolver la consulta de otra manera?

>Tendrias que resolver de otra manera. No es posible reordenar un OUTER
>JOIN en general. No me queda claro por que tus consultas se resuelven,
>segun tu, usando primero las tablas de mas "a la derecha" del outer
>join. Estas seguro que estas leyendo correctamente la salida de
>explain? Las tablas de "mas adentro" (mayor indentacion) son las
>primeras en ser recorridas.

Creo haberlo leido bien :-). Si, de hecho veo postgresql reordena algunos
joins, pero primero resuelve aquellos que necesite para el left join, luego
el left join, luego la tabla que tendría más selectividad. De hecho si yo
cambio el orden de los joins y los fuerzo con paréntesis, tengo una consulta
(por ejemplo por nombre y apellido) que devuelve resultados rápidos (de 2
minutos a 15 segundos, se que no parece un gran tiempo de espera, pero si se
considera que es atención al público, es mucho) pero por lo que aclaré en el
párrafo que sigue, esa consulta estaría optimizada por determinada búsqueda
y cuando el usuario decida (por ejemplo) buscar tipos de movimientos
asociados (u otro valor que no se encuentre en la tabla personas) esa
optimización se me vuelve en contra (mi consulta buscaría primero todas las
personas con sus datos y tablas asociadas) y hace el join con los
movimientos de un solo tipo.

Estoy viendo que la aplicación, en vez de armar la consulta agregando joins
al final del from:

select * from a left join b
, c -- se agrega la tabla necesario
where ...
and c = 'sarasa' -- se agrega el filtro

los inserte con paréntesis usando algún tag con comentarios:
select * from a /*PARENTESIS*/ /*JOIN_Y_CIERRA_PARENT*/ left join b
-- se reemplaza por parentesis y la consulta y más tags por si hay que
agregar más tablas
where ...
-- se agrega el filtro.

Pero en producción, es un equipo de cuatro procesadores y más memoria, está
haciendo un hash join, y el tiempo es aceptable (fuerza bruta!). Al
respecto, pregunto: ¿el hash join cuanta memoria consume para configurar
work_mem para la sesion? ¿dónde lo veo?

>> Tengo el inconveniente de que es una búsqueda por múltiple campos para
>> filtrar, por lo tanto, yo no puedo definir una consulta óptima para todas
>> las combinaciones de campos, necesitaría, si es posible que sea el query
>> planner el que la resuelva, más considerando que el usuario podría querer
>> traerme algo tipo "todos los expedientes del año" y luego otro usuario,
una
>> búsqueda por nombre y apellido.

>Hmm. Para esta situacion te sirve mucho la nueva caracteristica de
>"bitmap index scan", que permite usar mas de un indice en un recorrido a
>una tabla, con lo que se genera un mapa de bits que indica que tuplas
>cumplen la condicion; los mapas de bits generados por cada indice pueden
>ser mezclados usando AND y OR de bits, generando un mapa final de bits
>el cual se usa para un recorrido en orden del heap.

>En resumen, si tuvieras una tabla de muchas columnas, podrias tener
>indices simples (de una columna) en todas las posibles columnas con las
>que construir consultas, y dejar que el usuario escoja las condiciones
>de consulta; luego se usaran los indices que correspondan a las
>condiciones que el usuario escoge.

Me encantaría probarlo y comparar el sistema q tenemos contra 8.1devel pero
soy un consumidor de rpms para redhat 9 y no los encontré. Si alguien los
hizo... Gracias

Dario

"volvió mi adsl" - Dario