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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Bruno Wolff III <bruno(at)wolff(dot)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.