pgsql: Fix "element <@ range" cost estimation.

From: Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Fix "element <@ range" cost estimation.
Date: 2013-03-21 09:23:28
Message-ID: E1UIbia-0006Vb-5C@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Fix "element <@ range" cost estimation.

The statistics-based cost estimation patch for range types broke that, by
incorrectly assuming that the left operand of all range oeprators is a
range. That lead to a "type x is not a range type" error. Because it took so
long for anyone to notice, add a regression test for that case.

We still don't do proper statistics-based cost estimation for that, so you
just get a default constant estimate. We should look into implementing that,
but this patch at least fixes the regression.

Spotted by Tom Lane, when testing query from Josh Berkus.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/f897c4744fea221dfc7bbd277081edad41d1d58d

Modified Files
--------------
src/backend/utils/adt/rangetypes_selfuncs.c | 6 ++++--
src/test/regress/expected/rangetypes.out | 11 +++++++++++
src/test/regress/sql/rangetypes.sql | 9 +++++++++
3 files changed, 24 insertions(+), 2 deletions(-)

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Kevin Grittner 2013-03-21 15:20:11 Re: [COMMITTERS] pgsql: Fix "element <@ range" cost estimation.
Previous Message Alvaro Herrera 2013-03-20 21:20:23 pgsql: Allow extracting machine-readable object identity

Browse pgsql-hackers by date

  From Date Subject
Next Message Gilberto Castillo 2013-03-21 12:14:02 Re: [HACKERS] Call for Google Summer of Code mentors, admins
Previous Message Thom Brown 2013-03-21 08:53:15 Re: [pgsql-advocacy] Call for Google Summer of Code mentors, admins