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: 4914.990798446@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

Responses

Browse pgsql-hackers by date

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