Re: Query performance over a large proportion of data

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: smclellan(at)mintel(dot)com
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Query performance over a large proportion of data
Date: 2009-03-11 04:53:56
Message-ID: dcc563d10903102153n588d9d90q3a86cf27f4adca54@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, Mar 10, 2009 at 9:15 PM, Steve McLellan <smclellan(at)mintel(dot)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.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Jeff 2009-03-11 13:46:36 random_page_cost vs ssd?
Previous Message Steve McLellan 2009-03-11 03:30:32 Re: Query performance over a large proportion of data