On Dec 14, 2012, at 3:36 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:

> Evgeny Shishkin <itparan...@gmail.com> writes:
>> On Dec 14, 2012, at 3:09 AM, Andrew Dunstan <and...@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).
> 

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 :)  

>                       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

Reply via email to