Simon Riggs writes:
On Sat, 2008-09-06 at 13:06 +0100, Gregory Stark wrote:
Is that right? The materialize is just doing the same writing that the final
pass of the sort would have been doing. Did we discount the costs for sort for
that skipping writing that final pass when that was done?
IIRC the cost of the sort didn't include the final merge, so when we
avoided the final merge the cost model for the sort became accurate.
Perhaps we should add something when we don't do that.
It seems reasonable than an extra node should cost something anyhow, and
the per tuple cost is the current standard way of indicating that extra
cost.
Well, the problem with the previous coding was that the costs assigned
to the various nodes simply failed to add up, because the materialize
node injected by create_mergejoin_plan had not been accounted for at all
in the Path costs. It's fair to question whether cost_sort couldn't be
improved to create a more accurate estimate of what's likely to happen
at runtime given recent changes in the sort code --- but that would be a
distinct issue. I'm not entirely sure how to give cost_sort enough
context info, anyway.

regards, tom lane

Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedSep 6, '08 at 6:24p
activeSep 6, '08 at 6:24p
posts1
users1
websitepostgresql.org...
irc#postgresql

1 user in discussion

Tom Lane: 1 post

People

Translate

site design / logo © 2022 Grokbase