Re: I can't wait too much: Total runtime 432478.44 msec

"Fernando Papa" <fpapa(at)claxson(dot)com> writes:
> Thanks Tom. I vaccumed full every night. Now I drop function index and
> change the upper. Nothing change (I know, total time rise because we are
> doing other things on database now).

> -> Seq Scan on cont_publicacion
> (cost=0.00..5329.47 rows=10 width=35) (actual time=41.74..18004.75
> rows=97 loops=40)
> Filter: (((generar_vainilla = 'S'::character
> varying) OR (generar_vainilla = 's'::character varying)) AND
> (fecha_publicacion = (subplan)))
> SubPlan
> -> Aggregate (cost=11.86..11.86 rows=1
> width=8) (actual time=40.15..40.15 rows=1 loops=17880)

Something fishy going on here. Why did it switch to a seqscan,
considering it still (mistakenly) thinks there are only going to be 10
or 20 rows matching the generar_vainilla condition? How many rows have
generar_vainilla equal to 's' or 'S', anyway?

In any case, the real problem is to get rid of the subselect at the
Now that I look at your original query, I see that what you really seem
to be after is the publications with latest pub date among each group with
identical id_instalacion, id_contenido, and generar_vainilla. You would
probably do well to reorganize the query using SELECT DISTINCT ON, viz

SELECT * FROM
(SELECT DISTINCT ON (id_instalacion, id_contenido, generar_vainilla)
...
FROM ...
WHERE ...
ORDER BY
id_instalacion, id_contenido, generar_vainilla, fecha_publicacion DESC)
AS ss
ORDER BY fecha_publicacion desc
LIMIT 10
OFFSET 0

See the "weather reports" example in the SELECT reference page for
motivation.

regards, tom lane