Subject: Re: [HACKERS] PATCH: multivariate histograms and MCV lists
To: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
 Andres Freund <andres@anarazel.de>,
 Thomas Munro <thomas.munro@enterprisedb.com>,
 Mark Dilger <hornschnorter@gmail.com>,
 Adrien Nayrat <adrien.nayrat@dalibo.com>,
 Pg Hackers <pgsql-hackers@postgresql.org>
References: <20180310171906.gd6vyz6hnou2n3h7@alvherre.pgsql>
 <850c3b6b-2641-496c-4efc-500c720f7260@2ndquadrant.com>
 <ec49a434-b814-2cfa-f602-02a0cc9e518c@2ndquadrant.com>
 <CAEZATCW9AXzf+1T44B0=rBd8a0AD+pWO_PpkhApqLBE9JS1Cyg@mail.gmail.com>
 <66ba9c45-3b07-e5b6-fd11-15e75f6ee8e1@2ndquadrant.com>
 <CAEZATCUC8h6Osegq2Lw75Hc1NG=72JgNiiTQSSp9CpDCkQgakw@mail.gmail.com>
 <49348328-1a02-7e45-e50f-e1d4d0243c5c@2ndquadrant.com>
 <CAEZATCVKFCLi4NcXBU9ETvOO4WouVr8nfaUkeW6QUg_87YXBUg@mail.gmail.com>
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Message-ID: <fb20a5d8-032c-0678-10c8-522b695af7dd@2ndquadrant.com>
Date: Tue, 27 Mar 2018 19:42:39 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
 <CAEZATCVKFCLi4NcXBU9ETvOO4WouVr8nfaUkeW6QUg_87YXBUg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 03/27/2018 04:58 PM, Dean Rasheed wrote:
> On 27 March 2018 at 01:36, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote:
>> BTW I think there's a bug in handling the fullmatch flag - it should not
>> be passed to AND/OR subclauses the way it is, because then
>>
>>     WHERE a=1 OR (a=2 AND b=2)
>>
>> will probably set it to 'true' because of (a=2 AND b=2). Which will
>> short-circuit the statext_clauselist_selectivity, forcing it to ignore
>> the non-MCV part.
>>
> 
> I'm not sure that's true. Won't the outer call to
> mcv_update_match_bitmap() overwrite the value of fullmatch returned by
> the nested call, and set fullmatch to false because it has only seen 1
> attribute equality match? I think that's the correct result, but I
> think that's just luck.
> 
> The dubious part is the way fullmatch is calculated for OR clauses --
> I think for an OR clause we want to know the attributes matched in
> *every* subclause, rather than in *any* subclause, as we do for AND.
> So I think the only way an OR clause at the top-level should return a
> full match is if every sub-clause was a full match, for example:
> 
>   WHERE (a=1 AND b=2) OR (a=2 AND b=1)
> 

Yes, that seems like the right behavior.

> But then consider this:
> 
>   WHERE a=1 AND (b=1 OR b=2)
> 
> That should also potentially be a full match, but that can only work
> if mcv_update_match_bitmap() returned the set of matching attributes
> (eqmatches), rather than fullmatch, so that it can be merged
> appropriately in the caller. So for an OR clause, it needs to return
> eqmatches containing the list of attributes for which every sub-clause
> matched with equality against the MCV list, and in an outer AND clause
> that can be added to the outer eqmatches list, which is the list of
> attributes for which any sub-clause matched with equality.
> 

I think it's useful to see it transformed from:

    WHERE a=1 AND (b=1 OR b=2)

to

    WHERE (a=1 AND b=1) OR (a=1 AND b=2)

which is the case already handled above. And yes, tracking columns with
an equality seems reasonable.

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services