Re: [GENERAL] Performance of full outer join in 8.3 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [GENERAL] Performance of full outer join in 8.3
Date
Msg-id 14553.1240057927@sss.pgh.pa.us
Whole thread Raw
In response to Re: [GENERAL] Performance of full outer join in 8.3  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: [GENERAL] Performance of full outer join in 8.3  (Greg Stark <stark@enterprisedb.com>)
Re: [GENERAL] Performance of full outer join in 8.3  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> Hannu Krosing wrote:
>> Can't we make first cut at it by just running with timings on and then
>> compare ratios of running times - maybe with 2-3X tolerance - to catch
>> most obvious regressions ?

> The current regression tests are a series of yes/no answers to this 
> question: does the actual output match the expected output. Nothing like 
> as fuzzy as what you are suggesting is supported at all.

Quite aside from that, I don't think that's really the framework we
want.  The issues that I think would be worth having tests for are
questions like "will the planner push comparisons to constants down
through a full join?" (which was the bug that started this thread).
With a test methodology like the above, it wouldn't be enough to
write a test case that exercised the behavior; you'd have to make
sure that any alternative plan was an order of magnitude worse.

I'm inclined to think that some sort of fuzzy examination of EXPLAIN
output (in this example, "are there constant-comparison conditions in
the relation scans?") might do the job, but I'm not sure how we'd
go about that.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Marko Kreen
Date:
Subject: Re: [rfc] unicode escapes for extended strings
Next
From: Greg Stark
Date:
Subject: Re: [GENERAL] Performance of full outer join in 8.3