Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk? - Mailing list pgsql-performance

From Robert Haas
Subject Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
Date
Msg-id 603c8f071002101231k45e9161eyeacf9072219489eb@mail.gmail.com
Whole thread Raw
In response to Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?  (Bryce Nesbitt <bryce2@obviously.com>)
Responses Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
List pgsql-performance
On Wed, Feb 10, 2010 at 3:29 AM, Bryce Nesbitt <bryce2@obviously.com> wrote:
> Or, if you want to actually read that query plan, try:
> http://explain.depesz.com/s/qYq

Much better, though I prefer a text attachment...  anyhow, I think the
root of the problem may be that both of the subquery scans under the
append node are seeing hundreds of times more rows than they're
expecting, which is causing the planner to choose nested loops higher
up that it otherwise might have preferred to implement in some other
way.  I'm not quite sure why, though.

...Robert

pgsql-performance by date:

Previous
From: Scott Carey
Date:
Subject: Re: Linux I/O tuning: CFQ vs. deadline
Next
From: rama
Date:
Subject: perf problem with huge table