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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruno Wolff III <bruno(at)wolff(dot)to>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Recent 7.4 change slowed down a query by a factor of 3
Date: 2003-06-18 15:18:39
Message-ID: 21750.1055949519@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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?

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Bruno Wolff III 2003-06-18 15:43:32 Re: Recent 7.4 change slowed down a query by a factor of 3
Previous Message Bruno Wolff III 2003-06-18 15:02:10 Recent 7.4 change slowed down a query by a factor of 3