On Thu, 2007-12-06 at 19:19 -0500, Tom Lane wrote:
Since something needs to be done to that code anyway, I'm considering
applying the attached patch. It's a bit larger than I would normally
consider to be a good idea for an optional patch in late beta. But then
again I wouldn't have the
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I do have a longer term issue that there is no information provided by
EXPLAIN to allow us to differentiate these two conditions.
Sure there is: the new startup condition affects the estimated plan
startup cost (only) and the existing
Simon Riggs [EMAIL PROTECTED] writes:
I do have a longer term issue that there is no information provided by
EXPLAIN to allow us to differentiate these two conditions.
Sure there is: the new startup condition affects the estimated plan
startup cost (only) and the existing termination condition
Tom Lane [EMAIL PROTECTED] writes:
Any objections to applying the patch?
I like applying it.
You don't include any negative tests and corner cases as well; cases where the
new code shouldn't be disturbing the results such as a symmetric join or a
join against a single-row table. The comments
Gregory Stark [EMAIL PROTECTED] writes:
What about a merge join against an empty table? I suppose there would just be
no statistics?
Yeah. The defenses against silly results in mergejoinscansel should be
enough to prevent it from doing anything really insane.
regards,
Alvaro Herrera [EMAIL PROTECTED] writes:
Yes, but how can you tell by looking at the explain? I think the point
is that the fraction that would be skipped should be reported somehow.
It is: it's directly reflected in the startup cost. Previously, a
mergejoin would always have startup cost
There was some discussion earlier today
http://archives.postgresql.org/pgsql-performance/2007-12/msg00081.php
about how mergejoin cost estimation is not smart about the situation
where we will have to scan a lot of rows on one side of the join before
reaching the range of values found on the other
