Nikita Glukhov <n.gluhov@postgrespro.ru> writes:
> I found a problem with selectivity estimation for NULL-returning operators.
> matchingsel() is not ready to use as a restriction selectivity estimator for
> operators like our jsonpath operators @? and @@, because it calls operator
> function on values obtained from pg_statistic through plain FunctionCall2Coll()
> which does not accept NULL results (see mcv_selectivity() etc.).
Ah, good point.
> I'm not sure what we should to fix: operators or matchingsel().
Seems reasonable to let matchingsel support such cases.
> Introduced BoolFunctionCall2Coll() for replacing NULL with FALSE, that is used
> for calling non-comparison operators (I'm not sure that comparison can return
> NULLs).
Normally what we do is just invoke the function directly without going
through that layer. If you need to cope with NULL then the simplicity
of notation of FunctionCallN is lost to you anyway. I don't think we
particularly need an additional API that's intermediate between those.
> But if we will fix NULL handling, I think it would be worth to fix it
> everywhere in the selectivity estimation code.
I'm disinclined to move the goalposts so far for places where there have
been no complaints; especially not post-feature-freeze.
regards, tom lane
