compartiendo experiencias optimizaciones

Gente

Les queria contar mi experiencia y discutir con la
gente del foro algunas experiencias, me gustaria oir
sus opiniones al respecto.
Les cuento estoy haciendo un sistema usando postgresql
8.3 beta ( uso la beta porque tiene soporte nativo de
FTS) .

El sistema es un sistema de marcas y patentes y se
trata de buscar que marcas (publicadas en un boletin
de nuevas marcas )se parecen o podrian tener conflicto
con las marcas que tiene mi cliente. el termino "se
parece" es relativo a muchos criterios ( como suena (
fonetico) a como significa etc. no alargo para no
terminar en un correo interminable
la cuestion es que cosas como clase != '01' por
ejemplo
no se me optimizaba en las queries.
teniendo un indice por ese atributo o sea les muestro
una querie antes de optimizar y otra luego de
optimizar.

esta querie no optimizaba nada bien,

SELECT m.marca AS rmarca, b.clase, b.agte, m.acta AS
richeacta, m.reso_nro, m.acta, b.marca AS bmarca,
b.acta AS bacta, b.titular, b.cobertura,
b.nbol,m.carpeta , nombre , 2 as origen
FROM marca m, boletindbf b , cliente_base ,pais
WHERE cliente_base.id_ = m.cliente and
pais.id_ = m.pais and
pais.codigo ='AR' and
m.status_f not in('A' ,'B' ,'D' ,'N') and
m.activo=true and
m.marca::text <> 'ANEXA'::text AND
to_numero(b.clase::text) = to_numero(m.clase::text)
AND
b.agte::text <> '438'::text AND
to_tsvector('spanish'::regconfig, m.marca::text) @@
plainto_tsquery('spanish'::regconfig, b.marca::text)
por mas que los indices coincidieran .
que hize?

bueno la querie quedo asi.

SELECT m.marca AS rmarca, b.clase, b.agte, m.acta AS
racta, m.reso_nro, b.marca AS bmarca, b.acta AS bacta,
b.titular, b.cobertura, b.nbol,m.carpeta , nombre , 2
as origen
FROM marca m
INNER JOIN boletindbf b ON(
to_numero(b.clase::text) = to_numero(m.clase::text) )
INNER JOIN cliente_base m1 ON (m1.id_ = m.cliente)
INNER JOIN pais p1 ON (p1.id_ = m.pais)
WHERE
m.activo = true AND
goodagent(agte) and
goodpais(p1.codigo) AND
goodstatus(status_f ) and
goodmarca(m.marca) AND
to_tsvector('spanish'::regconfig, m.marca::text) @@
plainto_tsquery('spanish'::regconfig, b.marca::text)

dos cosas.
una use inner's joins. para las clausulas que no son
filtros. o sea donde matcheo id's .
y las expresiones xxxcampo <> 'talvalor' los converti
en funciones y cree indices con estos campos .
ej
CREATE INDEX vigi022
ON marca
USING btree
(activo, goodstatus(status_f::text),
goodmarca(marca::text));

ojo remarquemos 2 cosas en esto las funciones tienen
que ser immutables para poder indexar, dentro de esas
funciones se hace el return campoxx != '01' ;
ejemplo.
y el planner anduvo de maravillas o sea el plan se
volvio index scan y los tiempos mejoraron
dramaticamente.
queria compartir con uds mi experiencia porque tal vez
le podria servir a alguien mas, ademas de que alguien
podria correjirme algunas de las cosas aca expuestas o
que yo hice mal. pero andar mejor anda muuuucho mejor
sorry si se hizo largo el correo, saludos.
mdc
pd: espero se entienda :)

Los referentes más importantes en compra/ venta de autos se juntaron:
Demotores y Yahoo!
Ahora comprar o vender tu auto es más fácil. Vistá ar.autos.yahoo.com/