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

On Tue, Jul 05, 2005 at 04:54:50PM -0300, Dario wrote:

> 1) ¿Dónde se guarda el valor "número" que se asigna con el siguiente
> comando?
> ALTER TABLE tabla ALTER COLUMN columna SET STATISTICS = numero
>
> Se que esto determina la "profundidad" del histograma de pg_stats, pero
> necesitaría saber cual es el valor actual para una columna. Por defecto es
> el que indica postgresql.conf, pero si se lo cambiase a una columna
> particular, no se donde se guarda ese valor.
> Hice un alter t...tistics = 1000 y no recordaba a que columna se lo había
> hecho. Haciendo 'grep "set stat" $PGDATA/pg_log/*' encontré el comando que
> había tirado, pero quería saber en que tabla de sistema está.

En pg_attribute, la columna attstattarget. En la tabla pg_statistic
puedes saber los taman~os efectivos del histograma y de los valores mas
comunes, mirando el taman~o de los arrays de stanumbersN y/o stavaluesN,
alli donde stakindN tenga 1 para "valores mas comunes", 2 para
histograma.

> effective_cache_size = 10000 #sobre este parámetros tengo una duda, ¿este
> valor lo puedo ver en linux con el comando top?

Si.

> - ¿El "left join" obliga al query planner un determinado orden de
> resolución de queries? (según lo que entendí de la documentación, si. Por
> favor corrijanme si no es correcto)

Si, a menos que las condiciones del WHERE conviertan al OUTER JOIN en un
INNER JOIN (es decir, que una condicion del WHERE implique que el lado
"nulable" del outer join es un valor no nulo), cosa que hasta donde
puedo ver en tu primera consulta, no es el caso.

> - 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.

> 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.

> en el kernel cambié
> /proc/sys/kernel/shmall 33554432
> /proc/sys/kernel/shmmax 33554432

Ojo que shmall en general se mide en numero de paginas, mientras que
shmmax se mide en bytes.

--
Alvaro Herrera <alvherre[]alvh.no-ip.org> Architect, www.EnterpriseDB.com
<inflex> really, I see PHP as like a strange amalgamation of C, Perl, Shell
<crab> inflex: you know that "amalgam" means "mixture with mercury",
more or less, right?
<crab> i.e., "deadly poison"