Thread: Re: [COMMITTERS] pgsql: Fix "element <@ range" cost estimation.

Re: [COMMITTERS] pgsql: Fix "element <@ range" cost estimation.

From
Kevin Grittner
Date:
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



Re: [COMMITTERS] pgsql: Fix "element <@ range" cost estimation.

From
Heikki Linnakangas
Date:
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



Re: [COMMITTERS] pgsql: Fix "element <@ range" cost estimation.

From
Kevin Grittner
Date:
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



Re: [COMMITTERS] pgsql: Fix "element <@ range" cost estimation.

From
Dimitri Fontaine
Date:
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