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 teo...@sigaev.ru 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
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
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 possible to
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:
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 beta1
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
Teodor Sigaev teo...@sigaev.ru 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
Teodor Sigaev teo...@sigaev.ru 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
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
Teodor Sigaev teo...@sigaev.ru 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
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
12 matches
Mail list logo
