Re: Why does the number of rows are different in actual and estimated.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Evgeny Shishkin <itparanoia(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Claudio Freire <klaussfreire(at)gmail(dot)com>, AI Rumman <rummandba(at)gmail(dot)com>, postgres performance list <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Why does the number of rows are different in actual and estimated.
Date: 2012-12-13 23:36:54
Message-ID: 14685.1355441814@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Evgeny Shishkin <itparanoia(at)gmail(dot)com> writes:
> On Dec 14, 2012, at 3:09 AM, Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Evgeny Shishkin 2012-12-13 23:50:19 Re: Why does the number of rows are different in actual and estimated.
Previous Message Evgeny Shishkin 2012-12-13 23:13:29 Re: Why does the number of rows are different in actual and estimated.