--- On Thu, 19/2/09, Tom Lane 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 indexscans.
>
We h
Glyn Astill 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 the original disti
>
> 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
> shoul
Glyn Astill 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 plan you showed (th
> > 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
Glyn Astill 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)
>Index
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
