Re: [HACKERS] <> join selectivity estimate question - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] <> join selectivity estimate question
Date
Msg-id 84671.1512011289@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] <> join selectivity estimate question  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Responses Re: [HACKERS] <> join selectivity estimate question  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-hackers
Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> writes:
> On Fri, Jul 21, 2017 at 4:10 AM, Thomas Munro
> <thomas.munro@enterprisedb.com> wrote:
>> Please find attached a new version, and a test script I used, which
>> shows a bunch of interesting cases.  I'll add this to the commitfest.

> I added some "stable" tests to your patch taking inspiration from the
> test SQL file. I think those will be stable across machines and runs.
> Please let me know if those look good to you.

This seems to have stalled on the question of what the regression tests
should look like, which sems like a pretty silly thing to get hung up on
when everybody agrees the patch itself is OK.  I tried Ashutosh's proposed
test cases and was pretty unimpressed after noting that they passed
equally well against patched or unpatched backends.  In any case, as noted
upthread, we don't really like to expose exact rowcount estimates in test
cases because of the risk of platform to platform variation.  The more
usual approach for checking whether the planner is making sane estimates
is to find a query whose plan shape changes with or without the patch.
I messed around a bit till I found such a query, and committed it.
        regards, tom lane


pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan