From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Gregory Stark <stark(at)enterprisedb(dot)com>, simon(at)2ndQuadrant(dot)com |
Subject: | Re: [COMMITTERS] pgsql: Fix an oversight in the 8.2 patch that improved mergejoin |
Date: | 2008-09-06 18:23:35 |
Message-ID: | 21064.1220725415@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Simon Riggs <simon(at)2ndQuadrant(dot)com> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-09-06 20:18:08 | pgsql: Adjust psql's new \ef command to present an empty CREATE FUNCTION |
Previous Message | Simon Riggs | 2008-09-06 14:38:10 | Re: pgsql: Fix an oversight in the 8.2 patch that improved mergejoin |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-09-06 18:25:35 | Re: pg_dump/pg_restore items |
Previous Message | Tom Lane | 2008-09-06 18:14:26 | Re: hash index improving v3 |