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

Re: Planned changes to pg_am catalog

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Planned changes to pg_am catalog
Date: 2001-09-05 04:55:52
Message-ID: 200109050455.f854tqB02181@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Is this all addresssed?

> 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
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to

pgsql-hackers by date

Next:From: Tatsuo IshiiDate: 2001-09-05 09:28:42
Subject: CVS access
Previous:From: Bruce MomjianDate: 2001-09-05 04:48:35
Subject: Re: [GENERAL] Re: Debian's PostgreSQL packages

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