From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | marin(at)kset(dot)org |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Row number estimation... |
Date: | 2014-10-18 15:34:18 |
Message-ID: | 19642.1413646458@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
<marin(at)kset(dot)org> writes:
> Yesterday I was trying to calculate by hand the row number estimates using
> the examples from
> http://www.postgresql.org/docs/9.3/static/row-estimation-examples.html
> It is usually correct, except when you try to get an estimate near the
> first (or last) histogram bound. Let me demonstrate with an example:
> ...
> As no statistics are collected for the index (as stated in the
> pg_statistic documentation "No entry is made for an ordinary non-expression
> index column, however, since it would be redundant with the entry for the
> underlying table column.") it is mystery to me how these estimates are
> calculated. I tried to look at the code (my guess was that I could find it
> in btcostestimate) but I wasn't able to figure it out.
scalarineqsel() is where to look.
> Can somebody explain how are the estimates calculated when there is an
> index involved?
If the comparison value is outside the range recorded in the histogram,
and there's a suitable index available, the planner uses the index to
find out the actual column min or max rather than believing the histogram
completely. See get_actual_variable_range().
Possibly this behavior ought to be mentioned in the docs ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Wells Oliver | 2014-10-18 19:13:00 | 9.3 view / cross join / flat table solution |
Previous Message | Tom Lane | 2014-10-18 15:19:25 | Re: Integrating C++ singletons into postgresql extensions??? |