I wrote:
>> The implication of doing it like this would be that the default estimate
>> in the absence of any matching stats would be 0.5 (since eqsel defaults
>> to 1/ndistinct, and get_variable_numdistinct will report 2.0 for any
>> boolean-type expression it has no stats for). That's not a huge
I wrote:
> However, in the case at hand, the complaint basically is why aren't we
> treating the boolean function expression like a boolean variable, and
> looking to see if there are stats available for it, like this other
> bit in clause_selectivity:
> /*
> * A Var at th
Jehan-Guillaume de Rorthais writes:
> I faced a correlation problem on a query today and tried the usual trick
> consisting of using an functional index and rewriting the query to use it.
The core reason this isn't doing anything useful is that
clause_selectivity() is hard-wired to estimate the s
Hi,
I faced a correlation problem on a query today and tried the usual trick
consisting of using an functional index and rewriting the query to use it.
However, after writing the function, indexing it and rewriting the query, I
faced an optimizer behavior I was not expecting. I wrote a short scen
