Re: Statistics and selectivity estimation for ranges - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: Statistics and selectivity estimation for ranges
Date
Msg-id CAPpHfduTp5NOx_gbwfAxRc_OeOtN2_Yhtqo3o0S=x70ovtziww@mail.gmail.com
Whole thread Raw
In response to Re: Statistics and selectivity estimation for ranges  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: Statistics and selectivity estimation for ranges  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
Hi!

Thanks for your work on this patch!

On Tue, Mar 12, 2013 at 8:03 PM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
So, after some hacking, I ended up with this version. I find it more readable, I hope I didn't miss anything. This seems to produce results that are close, but not identical, to the original patch. I'm not sure where the discrepancy is coming from, or which patch is more correct in that respect. I'll continue from this tomorrow, but if you have the time, please take a look and let me know what you think.

I've read your explanation and version of patch. In general it seems correct to me.
There is one point why I have breaked up abstraction in some functions is infinities. For example, in calc_length_hist_frac one or both of length1 and length2 can be infinity. In the line
> frac = area / (length2 - length1);
you can get NaN result. I've especially adjusted the code to get more of less correct result in this case.

Another minor note about this line
> bin_width *= get_position(typcache, lower, &hist_lower[i],
>  &hist_lower[i + 1]);
ITSM it sould looks like
> bin_width -= 1.0 - get_position(typcache, lower, &hist_lower[i],
>   &hist_lower[i + 1]);
Imagine lower and upper bounds fall into same histogram bin. In this case we should subtract lengths of both parts which were cut in the left and in the right.

------
With best regards,
Alexander Korotkov.

pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]
Next
From: Magnus Hagander
Date:
Subject: Re: leaking lots of unreferenced inodes (pg_xlog files?), maybe after moving tables and indexes to tablespace on different volume