Re: Statistics and selectivity estimation for ranges

Jeff Davis <pgsql@j-davis.com>

From: Jeff Davis <pgsql@j-davis.com>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2012-12-10T19:21:44Z
Lists: pgsql-hackers
It looks like there are still some problems with this patch.

  CREATE TABLE foo(ir int4range);
  insert into foo select 'empty' from generate_series(1,10000);
  insert into foo select int4range(NULL, g, '(]')
    from generate_series(1,1000000) g;
  insert into foo select int4range(g, NULL, '[)')
    from generate_series(1,1000000) g;
  insert into foo select int4range(g, ((g*1.01)+10)::int4, '[]')
    from generate_series(1,1000000) g;
  CREATE TABLE bar(ir) AS select * from foo order by random();
  ANALYZE bar;

Now:
  EXPLAIN ANALYZE SELECT * FROM bar
    WHERE ir @> int4range(10000,20000);

The estimates are "-nan". Similar for many other queries.

And I have a few other questions/comments:

* Why is "summ" spelled with two "m"s? Is it short for "summation"? If
so, might be good to use "summation of" instead of "integrate" in the
comment.

* Why does get_length_hist_frac return 0.0 when i is the last value? Is
that a mistake?

* I am still confused by the distinction between rbound_bsearch and
rbound_bsearch_bin. What is the intuitive purpose of each?

* You use "constant value" in the comments in several places. Would
"query value" or "search key" be better?

Regards,
	Jeff Davis