Re: Making clausesel.c Smarter - Mailing list pgsql-hackers

From Claudio Freire
Subject Re: Making clausesel.c Smarter
Date
Msg-id CAGTBQpaszfb1arOHV3jT0L27iFzHgTHyhXQjnXNAmbqD1s1puA@mail.gmail.com
Whole thread Raw
In response to Re: Making clausesel.c Smarter  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: Making clausesel.c Smarter  (Claudio Freire <klaussfreire@gmail.com>)
List pgsql-hackers
On Mon, Apr 3, 2017 at 8:52 PM, David Rowley
<david.rowley@2ndquadrant.com> wrote:
>> One last observation:
>>
>> +        /*
>> +         * An IS NOT NULL test is a no-op if there's any other strict quals,
>> +         * so if that's the case, then we'll only apply this, otherwise we'll
>> +         * ignore it.
>> +         */
>> +        else if (cslist->selmask == CACHESEL_NOTNULLTEST)
>> +            s1 *= cslist->notnullsel;
>>
>> In some paths, the range selectivity estimation code punts and returns
>> DEFAULT_RANGE_INEQ_SEL. In those cases, if a not null test was
>> present, it should still be applied. It could make a big difference if
>> the selectivity for the nulltest is high.
>
> I'd say that the location that applies the DEFAULT_RANGE_INEQ_SEL
> should apply the nullfrac. Seems wrong to rely on a IS NOT NULL test
> to exists to estimate that properly. I don't think that needs done as
> part of this patch. I'd rather limit the scope since "returned with
> feedback" is already knocking at the door of this patch.

I agree, but this patch regresses for those cases if the user
compensated with a not null test, leaving little recourse, so I'd fix
it in this patch to avoid the regression.

Maybe you're right that the null fraction should be applied regardless
of whether there's an explicit null check, though.



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: delta relations in AFTER triggers
Next
From: Dilip Kumar
Date:
Subject: Re: parallel bitmapscan isn't exercised in regression tests