On 03.11.2011 10:42, Jeff Davis wrote:
On Wed, 2011-11-02 at 22:59 +0200, Heikki Linnakangas wrote:
This seems to be coming from the selectivity estimation function. The
selectivity function for<@ is scalargtsel, which is usually used for
scalar> and>=. That doesn't seem right. But what do we store in the
statistics for range types in the first place, and what would be the
right thing to do for selectivity estimation?
I'll have to think more about that, and it depends on the operator. It
seems like an easier problem for "contains a point" than "contains
another range" or "overlaps with another range".
Right now I don't have a very good answer, and even for the "contains a
point" case I'll have to think about the representation in pg_statistic.
I've committed this now, after some more cleanup. I removed the
selectivity estimation functions from operators where they were bogus,
so writing those is a clear TODO. But that can well be done as a
separate patch.
Thanks!
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
