Le mardi 25 mars 2008, Dimitri Fontaine a écrit :
> postgres=# create index idx_prefix on ranges using gist(prefix
> gist_prefix_range_ops);
> NOTICE: gpr_picksplit(): entryvec->n= 234 maxoff= 232 l= 176 r= 56 l+r=
> 232 unionL='01[0-7]' unionR='01[4-7]'
> NOTICE: gpr_picksplit(): v->spl_ldatum='01[0-7]' v->spl_rdatum='01[4-7]'
> ERROR: invalid memory alloc request size 3049878020
My previous tests were only done with REL8_2_STABLE cvs branch, I just redone
some tests with REL8_3_STABLE and got no error. The index is still buggy, in
the sense some requests returns different results with or without it
(enable_seqscan).
I've received some help on testing it too, and it seems the behavior is also
dependent on the architecture used. I'm using 32 bits linux arch, tests in 64
bit arch showed no error.
> The code is available at pgfoundry here:
> http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/prefix/prefix/
It still is :)
The easy way to test it is:
create table prefixes ( prefix text primary key, name text not null, shortname text,
state char default 'S',
check( state in ('S', 'R') ) ); comment on column prefixes.state is 'S: - R: reserved';
\copy prefixes from 'prefixes.fr.csv' with delimiter ; csv quote '"'
create table ranges as select prefix::prefix_range, name, shortname, state from prefixes ;
create index idx_prefix on ranges using gist(prefix gist_prefix_range_ops);
Then enable_seqscan to on or off, and queries such as select * from ranges where prefix @> '0100101234'; select * from
rangeswhere prefix @> '0146640123';
On my 8.3 testing, the former query gives the same result with or without
using the GiST index, the latter doesn't.
Regards,
--
dim