Re: Planned changes to pg_am catalog - Mailing list pgsql-hackers

On Sat, 14 Jul 2001, Tom Lane wrote:

> ... however, if you want to do some of the legwork yourself, here are
> the ideas I had about what to do:

OK. We'll dig into problem in august. At least we'll try.
How many possible problems would arise after changing of pg_opclass ?
Does existing code will handle this change somewhat automagically
or we have to find and modify relevant code ?

>
> pg_opclass should have, not just one row for each distinct opclass name,
> but one row for each supported combination of index AM and opclass name.
> Doing it this way would allow us to put additional info in pg_opclass
> rows --- right now, they're not really able to carry much information.
> The particular bit of info I want to add is a "keytype" column.  If this
> is not InvalidOid then it gives the OID of the index column datatype to
> be used when this opclass is selected.  For keytype to be different from
> data type, the amproc entries associated with the opclass would need to
> include a conversion routine to produce the index value given the input
> data columns --- ie, what the GIST code calls a compression routine.
> (In essence, this would be a form of functional index, no?)  Possibly
> pg_opclass should also include the amprocnum of the conversion routine;
> not sure how that ought to be handled.

compress/decompress isn't a type conversion. for example,
gist__int*_ops. indexed values and keytype are both int4 one dimensional
arrays and compress/decompress in this case do some real work.


>
> Note that this change would have a number of implications for the
> indexing of not only pg_opclass, but pg_amop and pg_amproc as well.
> In particular, pg_amop could lose its amopid column, and pg_amproc
> its amid column, since the opclass OID would be sufficient to indicate
> which index AM is meant for any row in these tables.  I have not worked
> out all the details, but I believe that these tables would become a lot
> more understandable this way.
>
> As for lossiness, I'm inclined to remove that column from pg_index
> altogether.  Instead, it should be a column in pg_amop, indicating that
> an index must be treated as lossy *for a particular operator in a
> particular opclass*.  Per previous discussion, this is the right level
> for the concept.  AFAIR, we could drop the WITH clause from CREATE INDEX
> altogether if we did this, which I think is the right thing --- the user
> should not be responsible for telling the system the properties of an
> index type and opclass.
>
> If you have time to start working out the details, that'd be great.
> I won't have time for it before mid-August probably.
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
Regards,    Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83