Jesper Krogh writes:
> Attached patch tries to align the behaviour
Applied with a bit of editorialization.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pg
Jesper Krogh writes:
> On 2011-02-17 23:20, Tom Lane wrote:
>> The proposed patch seems wrong to me: if we're estimating on the basis
>> of most-common-value fractions, the null_frac is already accounted for,
>> because it's not part of the MCV selectivity fractions. IOW, aren't you
>> double-cou
On 2011-02-17 23:20, Tom Lane wrote:
Jesper Krogh writes:
When something evaluates to "null" isn't included in the result,
shouldn't the query-planner
then take the null_frac into account when computing the estimate?
The proposed patch seems wrong to me: if we're estimating on the basis
of mos
Jesper Krogh writes:
> When something evaluates to "null" isn't included in the result,
> shouldn't the query-planner
> then take the null_frac into account when computing the estimate?
The proposed patch seems wrong to me: if we're estimating on the basis
of most-common-value fractions, the nul
Hi All.
The NULL element always suprises me in unpleasant ways.. my brain simply
cant really understand the logic, so please let me know if this is
one of the cases where I just should spend way more efforts into fixing
that instead.
I have a table with a "null_frac" of 0.5 and i have tested
