--- On Thu, 19/2/09, Tom Lane t...@sss.pgh.pa.us wrote:
Also, it'd be worth revisiting the question of whether
you really still
need enable_sort off ... personally, I'd think that
reducing
random_page_cost is a much saner way of nudging the planner
in the
direction of preferring
Hi Chaps,
We have a legacy application that used to have it's own sequential database
backend, and to fetch data out of it's tables commands such as find gt table
by index would be used.
What we have now is a driver in the middle that constructs sql to access the
data on pg8.3, typically of
Glyn Astill glynast...@yahoo.co.uk writes:
With enable_sort on this is the plan it chooses:
HashAggregate (cost=14.72..14.73 rows=1 width=9)
- Nested Loop (cost=0.00..14.72 rows=1 width=9)
- Index Scan using credit_index02 on credit (cost=0.00..7.04
rows=1 width=9)
Group (cost=0.00..11149194.48 rows=1 width=9)
That's just bizarre. Can you put together a
self-contained test case
for this? Also, what version is it exactly?
(8.3 is the wrong
answer.)
Thanks Tom,
It's 8.3.5, and I get the same results on all my servers (3 replicated servers
Glyn Astill glynast...@yahoo.co.uk writes:
I've slapped together a quick test case that gives the same results
with explain even when I have no data in the tables and haven't
analyzed them.
No, those aren't the same plans. In particular what's bothering me is
the lack of any sort in the first
No, those aren't the same plans. In particular
what's bothering me is
the lack of any sort in the first plan you showed (the one
with
HashAggregate at the top). That shouldn't be possible
because of the
ORDER BY --- a hash aggregate will deliver unsorted output
so there
should be a
Glyn Astill glynast...@yahoo.co.uk writes:
Ah, retracing my steps forget that; there's no sort because it's not the same
query at all.
OK, that explains why things didn't seem to add up.
Going back to my original point though, is there any way to get the planner
to choose a better plan for
