Re: Performance problem with semi-large tables

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: PFC <lists(at)boutiquenumerique(dot)com>
Cc: "Ken Egervari" <ken(at)upfactor(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Performance problem with semi-large tables
Date: 2005-01-30 17:50:02
Message-ID: 3657.1107107402@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

PFC <lists(at)boutiquenumerique(dot)com> writes:
>> For example, let's add another filter to get all the shipments with
>> release code '5' that are 7 days old or newer.
>>
>> ss.date >= current_date - 7

> It's the order by + limit which makes the query behaves badly, and which
> forces use of kludges to use the index. If you add another condition like
> that, it should be a breeze.

Actually, that date condition has its own problem, namely that the
compared-to value isn't a constant. The 8.0 planner is able to realize
that this is a pretty selective condition, but prior releases fall back
on a very pessimistic default estimate. I'm sure that has something to
do with Ken not being able to get it to use an index on date.

regards, tom lane

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message N S 2005-01-30 18:04:10 Re: Postgres server getting slow!!
Previous Message PFC 2005-01-30 11:10:55 Re: Performance problem with semi-large tables