On Thu, Sep 14, 2017 at 4:19 AM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > On Wed, Sep 6, 2017 at 11:14 PM, Ashutosh Bapat > <ashutosh.ba...@enterprisedb.com> wrote: >> On Fri, Jul 21, 2017 at 4:10 AM, Thomas Munro >> <thomas.mu...@enterprisedb.com> wrote: >>> That just leaves the question of whether we should try to handle the >>> empty RHS and single-value RHS cases using statistics. My intuition >>> is that we shouldn't, but I'll be happy to change my intuition and >>> code that up if that is the feedback from planner gurus. >> >> Empty RHS can result from dummy relations also, which are produced by >> constraint exclusion, so may be that's an interesting case. Single >> value RHS may be interesting with partitioned table with all rows in a >> given partition end up with the same partition key value. But may be >> those are just different patches. I am not sure. > > Can you elaborate on the constraint exclusion case? We don't care > about the selectivity of an excluded relation, do we? >
I meant, an empty RHS case doesn't necessarily need an empty table, it could happen because of a relation excluded by constraints (see relation_excluded_by_constraints()). So, that's not as obscure as we would think. But it's not very frequent either. But I think we should deal with that as a separate patch. This patch improves the estimate for some cases, while not degrading those in other cases. So, I think we can leave other cases for a later patch. > Any other views on the empty and single value special cases, when > combined with [NOT] EXISTS (SELECT ... WHERE r.something <> > s.something)? Looking at this again, my feeling is that they're too > obscure to spend time on, but others may disagree. > >>> 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. > > Hmm. But they show actual rows, not plan->plan_rows, and although the > former is interesting as a sanity check the latter is the thing under > test here. I missed this point while adopting the tests. Sorry. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
