Skip site navigation (1) Skip section navigation (2)

Re: Re: PG regression with row comparison when btree_gist is enabled (BUG)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: oleg(at)sai(dot)msu(dot)su, Denis de Bernardy <ddebernardy(at)yahoo(dot)com>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: Re: PG regression with row comparison when btree_gist is enabled (BUG)
Date: 2011-07-06 18:59:47
Message-ID: 24699.1309978787@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-testers
Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> On Wed, 2011-07-06 at 13:25 -0400, Tom Lane wrote:
>> Actually, I'd just been working on this myself.  I think the cleanest
>> solution will be to get rid of the duplicative logic by making
>> predtest.c use get_op_btree_interpretation().  That will require
>> changing get_op_btree_interpretation() so it can return amoplefttype
>> and amoprighttype too, but given the small number of callers, an API
>> change for it doesn't seem like a problem.

> Sounds good to me.

Committed that way.  Just for the archives' sake, the test case I was
using for the planner side of things was

create index tenk1p on tenk1 (twothousand) where twothousand <> 42;
explain select * from tenk1 where twothousand < 40;

which should use the partial index, but it was failing to prove the
implication when btree_gist was installed.

			regards, tom lane

In response to

pgsql-bugs by date

Next:From: Tom LaneDate: 2011-07-06 19:16:45
Subject: Re: BUG #6092: specific casting required for gist indexing of bigint
Previous:From: Jeff DavisDate: 2011-07-06 18:06:11
Subject: Re: Re: PG regression with row comparison when btree_gist is enabled (BUG)

pgsql-testers by date

Next:From: Josh BerkusDate: 2011-07-07 16:10:38
Subject: Re: Streaming replication on 9.1-beta2 after pg_restore is very slow
Previous:From: Jeff DavisDate: 2011-07-06 18:06:11
Subject: Re: Re: PG regression with row comparison when btree_gist is enabled (BUG)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group