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

From: Claudio Freire <klaussfreire(at)gmail(dot)com>
To: Evgeny Shishkin <itparanoia(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, 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-14 00:38:53
Message-ID: CAGTBQpaGP8j9FKLmR=8rFaxTtnfr6iozEbJF8sDt8_gz1ZQtkA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Thu, Dec 13, 2012 at 8:50 PM, Evgeny Shishkin <itparanoia(at)gmail(dot)com> wrote:
>>> 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).
>>
>
> May be in this case it is. I once wrote to this list regarding similar problem - joining 4 tables, result set are off by 2257 times - 750ms vs less then 1ms. Unfortunately the question was not accepted to the list.
>
> I spoke to Bruce Momjian about that problem on one local conference, he said shit happens :)

I think it's more likely a missing FK constraint.

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Kevin Grittner 2012-12-14 00:54:43 Re: hash join vs nested loop join
Previous Message Huan Ruan 2012-12-13 23:51:27 Re: hash join vs nested loop join