Re: Making clausesel.c Smarter

From: Claudio Freire <klaussfreire(at)gmail(dot)com>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Making clausesel.c Smarter
Date: 2017-04-04 00:19:22
Message-ID: CAGTBQpaszfb1arOHV3jT0L27iFzHgTHyhXQjnXNAmbqD1s1puA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Apr 3, 2017 at 8:52 PM, David Rowley
<david(dot)rowley(at)2ndquadrant(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2017-04-04 00:21:00 Re: parallel bitmapscan isn't exercised in regression tests
Previous Message Thomas Munro 2017-04-04 00:16:06 Re: delta relations in AFTER triggers