On 03/27/2018 07:03 PM, Dean Rasheed wrote:
> On 27 March 2018 at 14:58, Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
>> On 27 March 2018 at 01:36, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote:
>>> 4) handling of NOT clauses in MCV lists (and in histograms)
>>>
>>> The query you posted does not fail anymore...
>>>
>> Ah, it turns out the previous query wasn't actually failing for the
>> reason I thought it was -- it was failing because it had a
>> ScalarArrayOpExpr that was being passed to
>> mcv_clauselist_selectivity() because of the wrong list being passed to
>> it. I could see from the code that a NOT clause would have tripped it
>> up, but most NOT clauses actually get rewritten by negate_clause() so
>> they end up not being NOT clauses.
>>
>
> Thinking about that some, I think that the only NOT clauses this needs
> to actually worry about are NOTs of boolean Vars. Anything else that
> this code supports will have been transformed into something other
> than a NOT before reaching this point. Thus it might be much simpler
> to handle that as a special case in statext_is_compatible_clause() and
> mcv_update_match_bitmap(), rather than trying to support general NOT
> clauses, and going through a recursive call to
> mcv_update_match_bitmap(), and then having to merge bitmaps. NOT of a
> boolean Var could then be treated just like var=false, setting the
> appropriate attribute match entry if it's found in the MCV list. This
> would allow clauses like (a=1 and NOT b) to be supported, which I
> don't think currently works, because fullmatch won't get set.
>
Yes, I came to the same conclusion ;-) I'll send an updated patch later
today.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
