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

Hola. (linux kernel 2.4, postgresql 8.0, aplicación vb6, odbc)
Tengo temas con dudas y varias preguntas (estoy inspirado).
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á.

2)
¿ log_statement = 'all' (sin el plan de ejec) trae aparejado penalidades
de performance más allá de la contención a disco?

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

4)
- ¿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 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?
- Si es no ¿que parámetro de configuración o memoria puede estar
restringiendo una buena selección de plan de ejecución? Considerando que la
consulta no tiene más de 10 tablas, no creo que esté resolviendo por
"optimización genética" (¿es así en español?)

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.

Si bien estoy trabajando en un equipo chico (pentium III, 192 MB ram, IDE,
dedicado), estoy trabajando con un porcentaje menor de datos porque es un
equipo de testeo. En producción va a ir un pIV con scsi, chiche bombón.

Long life, little spam and prosperity.
----------------------------------------------------------------------------
--------------
"64 bits es 56 bits más de lo que necesito para ser feliz. Larga vida a mi
commodore 128"

A partir de acá, adjunto datos por si quieren leer más detalle, pero no es
mi intención que resuelvan algo que yo no esté haciendo, con la teoría me
alcanza :-)

Parámetros que se cambiaron del conf
listen_addresses = '*'
work_mem = 4096
maintenance_work_mem = 20480
wal_buffers = 16
checkpoint_segments = 8
effective_cache_size = 10000 (sobre este parámetros tengo una duda,
¿este valor me lo da el comando top?)
default_statistics_target = 20
log_statement = 'all'
stats_start_collector = true
stats_command_string = true
stats_row_level = true

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

CONSULTA (por si alguien quiere curiosear) (40 seg tanto desde la app como
desde psql),
cuando filtra por el campo bfp_fprevt:
----------------------------------------------------------------------------
----
SELECT DISTINCT bfp_fprevt as hca_fecreg, a.org_codigo, a.leg_numero,
a.tcc_codigo ,
a.hca_numero, a.hca_anio, a.hca_feclib, pdb.pdb_nomyap,
l.mtr_numero ,
vig_descr, hhc.hcc_carat , mca.leg_numero as mca_leg,
bfp.bfp_orgder
FROM bfp, rca r, hca a
left join leg l on (l.leg_numero = a.leg_numero)
left join pdb on (pdb.pdb_codigo = l.pdb_codigo)
left join vig on (vig.vig_codigo = l.vig_codigo)
left join mca on (mca.leg_numero = l.leg_numero)
left join hca_hca_crt hhc on ((hhc.org_codigo = a.org_codigo) AND
(hhc.tcc_codigo = a.tcc_codigo)
AND (hhc.hca_numero = a.hca_numero) AND
(hhc.hca_anio = a.hca_anio))
WHERE (a.org_codigo = r.org_codigo) AND (a.tcc_codigo = r.tcc_codigo)
AND (a.hca_numero = r.hca_numero) AND (a.hca_anio = r.hca_anio)
AND (r.rca_tiprel = 4) AND (a.org_codigo = bfp.org_codigo)
AND (a.tcc_codigo = bfp.tcc_codigo) AND (a.hca_numero = bfp.hca_numero)
AND (a.hca_anio = bfp.hca_anio)
AND (bfp_fprevt >= 146997) AND (bfp_fprevt <= 146997)
ORDER BY a.org_codigo,a.tcc_codigo,a.hca_anio,a.hca_numero,a.hca_feclib
----------------------------------------------------------------------------
----
Por lo que entendí y vi en el explain resuelve primero por hca_hca_crt,
luego por mca...
----------------------------------------------------------------------------
----
Reescribí el query de esta manera, forzando que resuelva bfp primero (4
segundos):

select aa.hca_fecreg, aa.org_codigo, aa.leg_numero, aa.tcc_codigo ,
aa.hca_numero, aa.hca_anio, aa.hca_feclib, pdb.pdb_nomyap,
l.mtr_numero ,
vig_descr, aa.hcc_carat , mca.leg_numero as mca_leg,
aa.bfp_orgder
from (SELECT DISTINCT bfp_fprevt as hca_fecreg, a.org_codigo, a.leg_numero,
a.tcc_codigo ,
a.hca_numero, a.hca_anio, a.hca_feclib,
hhc.hcc_carat, bfp.bfp_orgder
FROM bfp, rca r, hca a
left join hca_hca_crt hhc on ((hhc.org_codigo = a.org_codigo)
AND (hhc.tcc_codigo = a.tcc_codigo)
AND (hhc.hca_numero = a.hca_numero)
AND (hhc.hca_anio = a.hca_anio))
WHERE (a.org_codigo = bfp.org_codigo) AND (a.tcc_codigo =
bfp.tcc_codigo)
AND (a.hca_numero = bfp.hca_numero) AND (a.hca_anio = bfp.hca_anio)
AND (a.org_codigo = r.org_codigo) AND (a.tcc_codigo = r.tcc_codigo)
AND (a.hca_numero = r.hca_numero) AND (a.hca_anio = r.hca_anio) AND
(r.rca_tiprel = 4)
AND (bfp_fprevt >= 146997) AND (bfp_fprevt <= 146997)
ORDER BY a.org_codigo,a.tcc_codigo,a.hca_anio,a.hca_numero,
a.hca_feclib )
as aa
left join leg l on (l.leg_numero = aa.leg_numero)
left join pdb on (pdb.pdb_codigo = l.pdb_codigo)
left join vig on (vig.vig_codigo = l.vig_codigo)
left join mca on (mca.leg_numero = l.leg_numero)