On 6 September 2017 at 04:14, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > On Fri, Jul 21, 2017 at 4:10 AM, Thomas Munro > <thomas.mu...@enterprisedb.com> wrote: >> >> Thanks. Bearing all that in mind, I ran through a series of test >> scenarios and discovered that my handling for JOIN_ANTI was wrong: I >> thought that I had to deal with inverting the result, but I now see >> that that's handled elsewhere (calc_joinrel_size_estimate() I think). >> So neqjoinsel should just treat JOIN_SEMI and JOIN_ANTI exactly the >> same way. > > I agree, esp. after looking at eqjoinsel_semi(), which is used for > both semi and anti joins, it becomes more clear. > >> >> 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. > >> >> 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.
Why isn't this an open item for PG10? -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers