From: Tom Lane <tgl@sss.pgh.pa.us>
To: Evgeny Shishkin <itparanoia@gmail.com>
cc: Andrew Dunstan <andrew@dunslane.net>,
	Claudio Freire <klaussfreire@gmail.com>, AI Rumman <rummandba@gmail.com>,
	postgres performance list <pgsql-performance@postgresql.org>
Subject: Re: Why does the number of rows are different in actual and
 estimated.
In-reply-to: <F32F9E7A-1271-4864-AD2D-F95DC251D60D@gmail.com>
References: 
 <CAGoODpdaGPEOyAPkWvLD=0xfQ=k-a8B_fT=Tb6QJ0uNrDv=Hvg@mail.gmail.com>
	<50CA586A.30008@dunslane.net>
	<CAGTBQpZrERogVMvzAXouhvq-ERYtSUnR6QUk2EMJren0aB-PNQ@mail.gmail.com>
	<50CA6036.6000107@dunslane.net>
	<F32F9E7A-1271-4864-AD2D-F95DC251D60D@gmail.com>
Comments: In-reply-to Evgeny Shishkin <itparanoia@gmail.com>
	message dated "Fri, 14 Dec 2012 03:13:29 +0400"
Date: Thu, 13 Dec 2012 18:36:54 -0500
Message-ID: <14685.1355441814@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Evgeny Shishkin <itparanoia@gmail.com> writes:
> On Dec 14, 2012, at 3:09 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
>> Well, it looks like it's choosing a join order that's quite a bit different from the way the query is expressed, so the OP might need to play around with forcing the join order some.

> OP joins 8 tables, and i suppose join collapse limit is set to default 8. I thought postgresql's optimiser is not mysql's.

It's not obvious to me that there's anything very wrong with the plan.
An 8-way join that produces 150K rows is unlikely to run in milliseconds
no matter what the plan.  The planner would possibly have done the last
join step differently if it had had a better rowcount estimate, but even
if that were free the query would still have been 7 seconds (vs 8.5).

			regards, tom lane


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance