Re: GiST index on data types that require compression

Teodor Sigaev <teodor(at)stack(dot)net> 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 should be able to learn the key type OID
by examining the signature of the compression function.

The real question is whether the opclass is the right place for this
info. After thinking some more, I'm inclined to think not, since the
opclass isn't tied to a single index type. For example, poly_ops
might be lossy for GIST but not for another index type such as rtree.

It occurs to me that the structure of pg_opclass/pg_amop/pg_amproc
might be wrong. Perhaps pg_opclass should be indexed by (AM OID,
opclass name) not just opclass name, and then we could remove the
amopid columns from pg_amop and pg_amproc, since the OID of a
pg_opclass row would be sufficient to identify the access method.
This would allow us to put access-method-specific information into
pg_opclass. It would also be clearer whether a given AM supports
a given opclass name or not (right now, one has to see whether there
are matching entries in the other tables, which is pretty iffy
considering that one doesn't know how many there should be).

regards, tom lane