Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Bryce Nesbitt <bryce2(at)obviously(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
Date: 2010-02-10 20:31:58
Message-ID: 603c8f071002101231k45e9161eyeacf9072219489eb@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Wed, Feb 10, 2010 at 3:29 AM, Bryce Nesbitt <bryce2(at)obviously(dot)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message rama 2010-02-10 22:13:19 perf problem with huge table
Previous Message Scott Carey 2010-02-10 18:04:38 Re: Linux I/O tuning: CFQ vs. deadline