Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-performance by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group