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

From Thomas Munro
Subject Re: [HACKERS] <> join selectivity estimate question
Date
Msg-id CAEepm=2ZnwRe_5sm5B-6ZYe3F=iVtR6FSQ8HmqbbGj1xKSm4yQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] <> join selectivity estimate question  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] <> join selectivity estimate question  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Thu, Nov 30, 2017 at 4:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

Thank you for the original pointer and the commit.  Everything here
seems to make intuitive sense and the accompanying throw-away tests
that I posted above seem to produce sensible results except in some
cases that we discussed, so I think this is progress.  There is still
something pretty funny about the cardinality estimates for TPCH Q21
which I haven't grokked though.  I suspect it is crafted to look for a
technique we don't know (an ancient challenge set by some long retired
database gurus back in 1992 that their RDBMSs know how to solve,
hopefully not in the manner of a certain car manufacturer's air
pollution tests), but I haven't yet obtained enough round tuits to dig
further.  I will, though.

-- 
Thomas Munro
http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Commit fest 2017-11
Next
From: Beena Emerson
Date:
Subject: Re: [HACKERS] Runtime Partition Pruning