From: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
---|---|
To: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> |
Cc: | Tobias Brox <tobias(at)nordicbet(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Limit + group + join |
Date: | 2005-08-26 14:18:30 |
Message-ID: | 20050826071621.P12124@megazone.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Fri, 26 Aug 2005, Mark Kirkwood wrote:
> However being a bit brutal:
>
> set enable_mergejoin=false;
> set enable_hashjoin=false;
>
> explain select c.id from c join b on c_id=c.id group by c.id order by
> c.id desc limit 5;
> QUERY PLAN
>
> --------------------------------------------------------------------------------------------------
> Limit (cost=0.00..15.24 rows=5 width=4)
> -> Group (cost=0.00..243798.00 rows=80000 width=4)
> -> Nested Loop (cost=0.00..243598.00 rows=80000 width=4)
> -> Index Scan Backward using c_pkey on c
> (cost=0.00..1518.00 rows=80000 width=4)
> -> Index Scan using b_on_c on b (cost=0.00..3.01
> rows=1 width=4)
> Index Cond: (b.c_id = "outer".id)
> (6 rows)
>
> What is interesting is why this plan is being rejected...
Well, it expects 80000 probles into b_on_c to be more expensive than the
hash join and sort. I wonder what explain analyze shows for the original
and the version with the enables changed.
From | Date | Subject | |
---|---|---|---|
Next Message | Alan Stange | 2005-08-26 14:45:07 | difference in plan between 8.0 and 8.1? |
Previous Message | Richard Huxton | 2005-08-26 13:05:23 | Re: Inefficient queryplan for query with intersectable |