DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	b=VACFdKm7HYN6vhsfVgfr/jXpvpF8VaTwC2geCSfrOK/Ii/RWHd0EZ2BS91SuTBq3HB
	IR1cfvKZVxzwrz3QTMQmvwaIMjXPuZfZNHJB9Y1AdhKo0FVcFTkFZn/tH4Q2JS8WUXyO
	NC1gBBMntyqLPnqn/kyEo6UuC+fxoC4SeU/CQ=
MIME-Version: 1.0
In-Reply-To: <4B726E81.2060904@obviously.com>
References: <4B723042.7090406@obviously.com> <4B726E81.2060904@obviously.com>
Date: Wed, 10 Feb 2010 15:31:58 -0500
Message-ID: <603c8f071002101231k45e9161eyeacf9072219489eb@mail.gmail.com>
Subject: Re: Re: 512,600ms query becomes 7500ms... but why? Postgres
	8.3 query planner quirk?
From: Robert Haas <robertmhaas@gmail.com>
To: Bryce Nesbitt <bryce2@obviously.com>
Cc: pgsql-performance@postgresql.org
Content-Type: text/plain; charset=ISO-8859-1

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