Skip site navigation (1) Skip section navigation (2)

Re: GiST index on data types that require compression

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>
Cc: Dave Blasby <dblasby(at)refractions(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: GiST index on data types that require compression
Date: 2001-05-25 13:47:26
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> 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 whereby the user could specify
the type to be assumed for the key in the CREATE INDEX command (the
"haskeytype" stuff is the remaining traces of this).  This is brain dead
of course ... the correct way is to look at the pg_proc definition of
the compress function and see what type it's declared to return, not
rely on the user to get it right.

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 than the opclass needed?

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2001-05-25 14:23:01
Subject: Re: Bug#98643: plpgsql SELECT INTO causes trouble when assignment impossible (fwd)
Previous:From: Tatsuo IshiiDate: 2001-05-25 13:12:39
Subject: PQsetdbLogin bug?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group