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

On Wed, Jun 18, 2003 at 11:18:39 -0400,
  Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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?

I did a make distclean. I didn't do an initdb as I was able to restart
the database without a problem. I also tried a simpler query just doing
the distinct on without a where clause and the backwards index scan still
wasn't used.

I will try an initdb and then if that doesn't change things I will fetch
a new copy of the code from CVS, do another initdb and see what happens.