Re: Planned changes to pg_am catalog

From: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Planned changes to pg_am catalog
Date: 2001-07-16 14:46:49
Message-ID: Pine.GSO.4.33.0107161706500.24835-100000@ra.sai.msu.su
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-07-16 14:51:10 Re: handling NULLS in GiST
Previous Message Zeugswetter Andreas SB 2001-07-16 14:43:10 AW: handling NULLS in GiST