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/cvs...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:refix_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 ranges where 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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBH82EXlBXRlnbh1bkRAs5vAKCyI4DmB1TWE6YQ2BbnSi HdpP0TygCgz3Zg
RTwecqEEK922Yn2jhf0vK2k=
=p9jI
-----END PGP SIGNATURE-----