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

"Fernando Papa" <fpapa@claxson.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