Re: Query performance over a large proportion of data - Mailing list pgsql-performance

From Scott Marlowe
Subject Re: Query performance over a large proportion of data
Date
Msg-id dcc563d10903102153n588d9d90q3a86cf27f4adca54@mail.gmail.com
Whole thread Raw
In response to Re: Query performance over a large proportion of data  (Steve McLellan <smclellan@mintel.com>)
List pgsql-performance
On Tue, Mar 10, 2009 at 9:15 PM, Steve McLellan <smclellan@mintel.com> wrote:
> Thanks - the nested loop is indeed causing problems - reducing
> seq_page_cost had the same effect of removing the nested loop for this
> query. We'd noticed the poor row count estimation. Increasing the statistics
> doesn't seem to have much effect, but we'll have more of a go with it.

More than likely it's the sequential page cost versus the cpu_xxx cost
setttings that's really making the difference.  I.e. if you raised the
cpu_xxx settings you'd get the same result.  But I'm not sure, just a
guess.

pgsql-performance by date:

Previous
From: Steve McLellan
Date:
Subject: Re: Query performance over a large proportion of data
Next
From: Jeff
Date:
Subject: random_page_cost vs ssd?