Re: Recent 7.4 change slowed down a query by a factor of 3

Bruno Wolff III <bruno@wolff.to> writes:
> The query below was running in a bit under 300ms on a version of 7.4
> from less than a week ago until I updated to the version from last night.
> Now it takes about 800ms using a significantly different plan.

Something fishy here.  Will it use the right plan if you set
enable_seqscan off?

I did

bogus=# create table crate(areaid text, touched timestamp);
CREATE TABLE
bogus=# create index crate_touched on crate(areaid, touched);
CREATE INDEX

and then explained your query:

 GroupAggregate  (cost=64.14..66.48 rows=67 width=40)
   ->  Sort  (cost=64.14..64.64 rows=200 width=40)
         Sort Key: (touched >= (('now'::text)::timestamp(6) without time zone + '-2 years'::interval))
         ->  Subquery Scan current  (cost=0.00..56.50 rows=200 width=40)
               Filter: (touched >= (('now'::text)::timestamp(6) without time zone + '-10 years'::interval))
               ->  Unique  (cost=0.00..54.50 rows=200 width=40)
                     ->  Index Scan Backward using crate_touched on crate  (cost=0.00..52.00 rows=1000 width=40)

which looks perfectly reasonable.  Obviously, with no data or statistics
the estimates are not to be trusted, but it sure looks to me like CVS
tip should still be able to generate the right plan.  Did you do a full
'make clean' and rebuild when you updated?

            regards, tom lane