pgsql: Fix "element <@ range" cost estimation.
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(-)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Heikki Linnakangas <heikki.linnakangas@iki.fi> wrote:
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.
Something is still wrong. When I run `make check-world` everything
passes, but `make installcheck-world` on a fresh initdb with
default configuration yields this:
*** /home/kgrittn/pg/master/src/test/regress/expected/rangetypes.out 2013-03-21 09:17:39.445690793 -0500
--- /home/kgrittn/pg/master/src/test/regress/results/rangetypes.out 2013-03-21 10:13:20.201683022 -0500
***************
*** 1048,1058 ****
create index test_range_elem_idx on test_range_elem (i);
insert into test_range_elem select i from generate_series(1,100) i;
select count(*) from test_range_elem where i <@ int4range(10,50);
! count
! -------
! 40
! (1 row)
!
drop table test_range_elem;
--
-- Btree_gist is not included by default, so to test exclusion
--- 1048,1054 ----
create index test_range_elem_idx on test_range_elem (i);
insert into test_range_elem select i from generate_series(1,100) i;
select count(*) from test_range_elem where i <@ int4range(10,50);
! ERROR: type 23 is not a range type
drop table test_range_elem;
--
-- Btree_gist is not included by default, so to test exclusion
======================================================================
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 21.03.2013 17:20, Kevin Grittner wrote:
Something is still wrong. When I run `make check-world` everything
passes, but `make installcheck-world` on a fresh initdb with
default configuration yields this:
Huh, that's strange. It works for me, and the build farm is happy. I
must ask: are you sure the server is running with fresh binaries? If it
still fails, could you try to get a stack trace or something?
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
Huh, that's strange. It works for me, and the build farm is
happy. I must ask: are you sure the server is running with fresh
binaries? If it still fails, could you try to get a stack trace
or something?
Hmm. Just to be sure I used maintainer-clean and another initdb
and now I don't see it. If I see it again I'll get a stack trace,
but for now it's not throwing the error.
Sorry for the noise.
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Kevin Grittner <kgrittn@ymail.com> writes:
Hmm. Just to be sure I used maintainer-clean and another initdb
and now I don't see it. If I see it again I'll get a stack trace,
but for now it's not throwing the error.
It happened to me way too many times to have to do maintainer-clean for
reasons I didn't understand, and I've been told that when it happens,
you have to look at the how the build is done.
It might be useful to talk some more about those strange cases where we
have to maintainer-clean our local copy for things to get back to normal
so that we are able to fix the build scripts down the road.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers