I wrote:
> I think what we have to do is use a different dummy value for the node
> label of a pushed-down allTheSame tuple than we do for end-of-string.
> This requires widening the node labels from uint8 to (at least) int16.
> However, I think that's essentially free because pass-by-value node
>
Teodor Sigaev writes:
>> The point I'm making is that the scenario your test case exposes is not
>> an infinite loop of picksplits, but an infinite loop of choose calls.
> Thank you, now I see what I missed before. After some brainstorming, it's
> possible to use '\0' only as end of string marke
On Fri, May 30, 2014 at 08:19:07PM +0400, Teodor Sigaev wrote:
> >If we bump the system catalog version, pg_upgrade can mark those indexes
> >as invalid and output a script to reindex them.
> >
>
> Between 9.3 - 9.4 catalog version is changed anyway.
Right. I was thinking of beta users between b
If we bump the system catalog version, pg_upgrade can mark those indexes
as invalid and output a script to reindex them.
Between 9.3 - 9.4 catalog version is changed anyway.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.siga
On Fri, May 30, 2014 at 06:55:18PM +0400, Teodor Sigaev wrote:
> >The point I'm making is that the scenario your test case exposes is not
> >an infinite loop of picksplits, but an infinite loop of choose calls.
>
> Thank you, now I see what I missed before. After some brainstorming,
> it's possibl
The point I'm making is that the scenario your test case exposes is not
an infinite loop of picksplits, but an infinite loop of choose calls.
Thank you, now I see what I missed before. After some brainstorming, it's
possible to use '\0' only as end of string marker. The idea is: when we split
Teodor Sigaev writes:
>> I don't think that checkAllTheSame is broken, but it probably would be
>> after this patch --- ISTM you're breaking the corner case described in the
>> header comment for checkAllTheSame, where we need to force splitting of a
>> set of existing tuples that the opclass can'
I don't think that checkAllTheSame is broken, but it probably would be
after this patch --- ISTM you're breaking the corner case described in the
header comment for checkAllTheSame, where we need to force splitting of a
set of existing tuples that the opclass can't distinguish.
INHO, this patch wi
Teodor Sigaev writes:
> create table xxx ( t text);
> insert into xxx select 'x' || v::text from generate_series(1, 291) as v;
> insert into xxx values ('');
> create index xxxidx on xxx using spgist (t);
Fun!
> And postgres will eat memory forever. It seems to me that checkAllTheSame
> wron
Hi!
create table xxx ( t text);
insert into xxx select 'x' || v::text from generate_series(1, 291) as v;
insert into xxx values ('');
create index xxxidx on xxx using spgist (t);
And postgres will eat memory forever. It seems to me that checkAllTheSame
wrongly decides that all tuples are the
Teodor Sigaev writes:
> SP-GiST has a bug during creation:
> % create table ranges as select int4range( (random()*5)::int,
> (random()*5)::int+5) as range
> from generate_series(1,100) x;
> % create index ranges_range_spgist_idx on ranges using spgist(
SP-GiST has a bug during creation:
% create table ranges as select int4range( (random()*5)::int,
(random()*5)::int+5) as range
from generate_series(1,100) x;
% create index ranges_range_spgist_idx on ranges using spgist(range);
ERROR: unexpected spgdoin
12 matches
Mail list logo