AW: [HACKERS] GiST index on data types that require compression

2001-05-27 Thread Zeugswetter Andreas SB
> So, may by add to pg_opclass two fields? > bool is_varlena_key > bool is_lossy_compress Those are both properties of the compress function, the index method or the key type. I do not think it has anything to do with operator classes (comparison functions), and thus would be wrong in pg_opclas

Re: [HACKERS] GiST index on data types that require compression

2001-05-25 Thread Tom Lane
Teodor Sigaev <[EMAIL PROTECTED]> writes: > So, may by add to pg_opclass two fields? > bool is_varlena_key > bool is_lossy_compress Certainly not 'is_varlena_key', since that's not all the info you need about the key datatype --- a type OID would be more appropriate. But it seems to me that we sh

Re: [HACKERS] GiST index on data types that require compression

2001-05-25 Thread Teodor Sigaev
> So, may by add to pg_opclass two fields? > bool is_varlena_key > bool is_lossy_compress Sorry, I was wrong. In GiST, index_formtuple doesn't know about size of fixed-length type of keys, because only loadable module has information about structure of key. So, may be it needs to have funct

Re: [HACKERS] GiST index on data types that require compression

2001-05-25 Thread Teodor Sigaev
> What I find just about as objectionable as the old haskeytype hack is > that the user has to tell you whether the index is lossy or not. This > should be a property available from the system catalogs. Not sure where > to put it; do we need another column in pg_opclass, or is someplace > other

Re: [HACKERS] GiST index on data types that require compression

2001-05-25 Thread Tom Lane
Oleg Bartunov <[EMAIL PROTECTED]> writes: > compress fully supports fixed-length and varlena types. The problem is > index_formtuple - types of key and column could be different > (example - polygon, where column has varlena type but key is fixed-length) Right. There used to be a horrible kluge

Re: [HACKERS] GiST index on data types that require compression

2001-05-24 Thread Tom Lane
Dave Blasby <[EMAIL PROTECTED]> writes: > So far, it doesnt work. Only one of my GiST support functions is called > (the compress function), after that I get the error message: > # create index qq on tp3 using gist (the_geom gist_geometry_ops) with > (islossy); > ERROR: index_formtuple: data ta

[HACKERS] GiST index on data types that require compression

2001-05-24 Thread Dave Blasby
I'm trying to get my geometric type to spatially index. I tried RTrees, but they dont like objects that are bigger than 8k. I'm now trying to get a GiST index to index based on the bounding box thats contained inside the geometry. So the index is on a GEOMETRY type, but the index is only acting