Re: [COMMITTERS] 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(-)

Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)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

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

Heikki Linnakangas <hlinnakangas(at)vmware(dot)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

Kevin Grittner <kgrittn(at)ymail(dot)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