Thread: Unused system table columns
The following system table columns are currently unused and don't appear to be in the line of resurrection. pg_language.lancompiler pg_operator.oprprec pg_operator.oprisleft pg_proc.probyte_pct pg_proc.properbyte_cpu pg_proc.propercall_cpu pg_proc.prooutin_ratio pg_shadow.usetrace pg_type.typprtlen pg_type.typreceive pg_type.typsend This adds up to quite some space -- on disk and on the screen. I think we should remove them. -- Peter Eisentraut peter_e@gmx.net
Agreed, and with schemas coming in, we are going to break so much stuff anyway we should remove them. --------------------------------------------------------------------------- Peter Eisentraut wrote: > The following system table columns are currently unused and don't appear > to be in the line of resurrection. > > pg_language.lancompiler > pg_operator.oprprec > pg_operator.oprisleft > pg_proc.probyte_pct > pg_proc.properbyte_cpu > pg_proc.propercall_cpu > pg_proc.prooutin_ratio > pg_shadow.usetrace > pg_type.typprtlen > pg_type.typreceive > pg_type.typsend > > This adds up to quite some space -- on disk and on the screen. I think we > should remove them. > > -- > Peter Eisentraut peter_e@gmx.net > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
For all intent and purpose, pg_index.indisprimary can be added to that list. Can't make a primary key without a pg_constraint entry. The below are also reported unused by the documentation: pg_class.relukeys pg_class.relfkeys pg_class.relrefs pg_index.indisclustered pg_index.indreference On Mon, 2002-07-15 at 18:53, Peter Eisentraut wrote: > The following system table columns are currently unused and don't appear > to be in the line of resurrection. > pg_language.lancompiler > pg_operator.oprprec > pg_operator.oprisleft > pg_proc.probyte_pct > pg_proc.properbyte_cpu > pg_proc.propercall_cpu > pg_proc.prooutin_ratio > pg_shadow.usetrace > pg_type.typprtlen > pg_type.typreceive > pg_type.typsend > > This adds up to quite some space -- on disk and on the screen. I think we > should remove them.
On Tue, 2002-07-16 at 03:53, Peter Eisentraut wrote: > The following system table columns are currently unused and don't appear > to be in the line of resurrection. > > pg_language.lancompiler > pg_operator.oprprec > pg_operator.oprisleft > pg_proc.probyte_pct > pg_proc.properbyte_cpu > pg_proc.propercall_cpu > pg_proc.prooutin_ratio > pg_shadow.usetrace > pg_type.typprtlen > pg_type.typreceive > pg_type.typsend pg_type.typreceive and pg_type.typsend are unused, but I think they should be saved for use as converters from/to unified binary wire protocol (as their name implies ;) once we get at it. The alternative would be yet another system table which would allow us to support unlimited number of to/from converters for different wire protocols, but it will definitely be easier to start with typreceive/typsend. --------------- Hannu
Hannu Krosing wrote: > On Tue, 2002-07-16 at 03:53, Peter Eisentraut wrote: > > The following system table columns are currently unused and don't appear > > to be in the line of resurrection. > > > > pg_language.lancompiler > > pg_operator.oprprec > > pg_operator.oprisleft > > pg_proc.probyte_pct > > pg_proc.properbyte_cpu > > pg_proc.propercall_cpu > > pg_proc.prooutin_ratio > > pg_shadow.usetrace > > pg_type.typprtlen > > pg_type.typreceive > > pg_type.typsend > > pg_type.typreceive and pg_type.typsend > are unused, but I think they should be saved for use as converters > from/to unified binary wire protocol (as their name implies ;) once we > get at it. > > The alternative would be yet another system table which would allow us > to support unlimited number of to/from converters for different wire > protocols, but it will definitely be easier to start with > typreceive/typsend. We can always re-add the columns them. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Tue, 2002-07-16 at 04:55, Bruce Momjian wrote: > Hannu Krosing wrote: > > On Tue, 2002-07-16 at 03:53, Peter Eisentraut wrote: > > > The following system table columns are currently unused and don't appear > > > to be in the line of resurrection. > > > > > > pg_language.lancompiler > > > pg_operator.oprprec > > > pg_operator.oprisleft > > > pg_proc.probyte_pct > > > pg_proc.properbyte_cpu > > > pg_proc.propercall_cpu > > > pg_proc.prooutin_ratio > > > pg_shadow.usetrace > > > pg_type.typprtlen > > > pg_type.typreceive > > > pg_type.typsend > > > > pg_type.typreceive and pg_type.typsend > > are unused, but I think they should be saved for use as converters > > from/to unified binary wire protocol (as their name implies ;) once we > > get at it. > > > > The alternative would be yet another system table which would allow us > > to support unlimited number of to/from converters for different wire > > protocols, but it will definitely be easier to start with > > typreceive/typsend. > > We can always re-add the columns them. But would it not be nice if we could add uniform binary protocol without requiring initdb ? If the main concern is disk space, just set them to NULL . ------------ Hannu
Hannu Krosing wrote: > > > The alternative would be yet another system table which would allow us > > > to support unlimited number of to/from converters for different wire > > > protocols, but it will definitely be easier to start with > > > typreceive/typsend. > > > > We can always re-add the columns them. > > But would it not be nice if we could add uniform binary protocol without > requiring initdb ? Seems impossible that would ever happen without an initdb. > If the main concern is disk space, just set them to NULL . Good point, but it does confuse developers. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Tue, 2002-07-16 at 05:19, Bruce Momjian wrote: > Hannu Krosing wrote: > > > > The alternative would be yet another system table which would allow us > > > > to support unlimited number of to/from converters for different wire > > > > protocols, but it will definitely be easier to start with > > > > typreceive/typsend. > > > > > > We can always re-add the columns them. > > > > But would it not be nice if we could add uniform binary protocol without > > requiring initdb ? > > Seems impossible that would ever happen without an initdb. Why? We already have a binary protocol, the only part I see missing for making it _universal_ is binary representation of types + alignment issues. If we just write the functions for typreceive/send (mostly identity+padding for x86, some byte swapping on SPARC (or vice versa)) and start using them when cursor is in binary mode plus we determine minimal acceptable alignments then we are (almost?) there for output. For input, putting in PREPARE/EXECUTE with binary argument passing will likely need initdb (maybe not), but _temporarily_ throwing out _just_ typreceive seems weird. > > If the main concern is disk space, just set them to NULL . > > Good point, but it does confuse developers. But it confuses them _less_ than our current practice of putting unused copies of typinput/typoutput there, and nobody seems too confused even now ;) And keeping them as NULL may be used to indicate than no conversion is needed and data can be sent as-is like we do now, so we are even doing the right thing for this scenario, all without any coding ;) -------------- Hannu
Hannu Krosing wrote: > On Tue, 2002-07-16 at 05:19, Bruce Momjian wrote: > > Hannu Krosing wrote: > > > > > The alternative would be yet another system table which would allow us > > > > > to support unlimited number of to/from converters for different wire > > > > > protocols, but it will definitely be easier to start with > > > > > typreceive/typsend. > > > > > > > > We can always re-add the columns them. > > > > > > But would it not be nice if we could add uniform binary protocol without > > > requiring initdb ? > > > > Seems impossible that would ever happen without an initdb. > > Why? It is inconceivable we would add such a feature without a major release, and every major release requires an initdb. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Tue, 2002-07-16 at 05:43, Bruce Momjian wrote: > Hannu Krosing wrote: > > On Tue, 2002-07-16 at 05:19, Bruce Momjian wrote: > > > Hannu Krosing wrote: > > > > > > The alternative would be yet another system table which would allow us > > > > > > to support unlimited number of to/from converters for different wire > > > > > > protocols, but it will definitely be easier to start with > > > > > > typreceive/typsend. > > > > > > > > > > We can always re-add the columns them. > > > > > > > > But would it not be nice if we could add uniform binary protocol without > > > > requiring initdb ? > > > > > > Seems impossible that would ever happen without an initdb. > > > > Why? > > It is inconceivable we would add such a feature without a major release, > and every major release requires an initdb. Even if we change nothing in system tables ;) As I explained, we already have a binary protocol. What I proposed, would make it usable between hosts with different CPU's by inserting appropriate functions for types - without typsend(), i.e typesend=NULL the behaviour would be exactly as it is now, but people would be free to experiment without fatally breaking all other installations. Technically this will probably not extend much beyond modifying function printtup_internal in src/backend/access/common/printtup.c /* ----------------* printtup_internal* We use a different data prefix, e.g. 'B' instead of 'D' to* indicate a tuple in internal(binary) form.** This is largely same as printtup,except we don't use the typout func.* ----------------*/ static void printtup_internal(HeapTuple tuple, TupleDesc typeinfo, DestReceiver *self) The hard part will be agreeing on the actual data format(s), but this can be postponed by having this implementation where people can experiment. After looking at the code again, it seems that we must have already solved (most) alignment issues in printtup, so the task is just agreeing on types' on-wire representations. ------------------ Hannu
Hannu Krosing wrote: > Technically this will probably not extend much beyond modifying function > printtup_internal in src/backend/access/common/printtup.c > > /* ---------------- > * printtup_internal > * We use a different data prefix, e.g. 'B' instead of 'D' to > * indicate a tuple in internal (binary) form. > * > * This is largely same as printtup,except we don't use the typout func. > * ---------------- > */ > static void > printtup_internal(HeapTuple tuple, TupleDesc typeinfo, DestReceiver > *self) > > > The hard part will be agreeing on the actual data format(s), but this > can be postponed by having this implementation where people can > experiment. > > After looking at the code again, it seems that we must have already > solved (most) alignment issues in printtup, so the task is just agreeing > on types' on-wire representations. I just can't imagine adding anything like that in a minor release. In fact, I most would object to adding it in a minor release because we don't add features in a minor release. Now, if you want it kept because you may want to work in that area, we can surely do that. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Rod Taylor <rbt@zort.ca> writes:
> For all intent and purpose, pg_index.indisprimary can be added to that
> list. Can't make a primary key without a pg_constraint entry.
I disagree. For one thing, there are clients that look at that column.
There's no percentage in breaking them to gain zero (and it will be
zero, because of alignment considerations...)
indisclustered is currently pretty useless, but may become less so
if CLUSTER gets upgraded to usefulness, so I'm not in favor of deleting
that either.
No strong attachment to the other stuff mentioned so far.
regards, tom lane
Tom Lane wrote: > Rod Taylor <rbt@zort.ca> writes: > > For all intent and purpose, pg_index.indisprimary can be added to that > > list. Can't make a primary key without a pg_constraint entry. > > I disagree. For one thing, there are clients that look at that column. > There's no percentage in breaking them to gain zero (and it will be > zero, because of alignment considerations...) Yes, pgaccess uses it, as I remember. Would be nice if it was accurate. > > indisclustered is currently pretty useless, but may become less so > if CLUSTER gets upgraded to usefulness, so I'm not in favor of deleting > that either. Yea, I can see that being useful some day. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Hannu Krosing <hannu@tm.ee> writes:
>> We can always re-add the columns them.
> But would it not be nice if we could add uniform binary protocol without
> requiring initdb ?
That won't happen, because the existing contents of those columns are
completely useless for a binary-protocol feature.
If we do ever add such a feature, we'd be better off adding new columns
with a different name, just to avoid confusion over what's supposed to
be there. (For example: extant pg_dump scripts for user-defined types
will try to load wrong values into those columns if given a chance.
We *must* use new names for those slots in CREATE TYPE to avoid that
pitfall, and so we might as well change the system column name too.)
regards, tom lane
> > I disagree. For one thing, there are clients that look at that column. > > There's no percentage in breaking them to gain zero (and it will be > > zero, because of alignment considerations...) > > Yes, pgaccess uses it, as I remember. Would be nice if it was accurate. Not to mention phpPgAdmin, psql, pg_dump, TOra, pgadmin, etc. Chris
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Yes, pgaccess uses it, as I remember. Would be nice if it was accurate.
Eh? It is, AFAIK.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Yes, pgaccess uses it, as I remember. Would be nice if it was accurate. > > Eh? It is, AFAIK. Oh, I can't remember if it was fixed or broken. Certainly it is nice to have for apps like pgaccess. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Tue, 2002-07-16 at 11:13, Tom Lane wrote: > Hannu Krosing <hannu@tm.ee> writes: > >> We can always re-add the columns them. > > > But would it not be nice if we could add uniform binary protocol without > > requiring initdb ? > > That won't happen, because the existing contents of those columns are > completely useless for a binary-protocol feature. > > If we do ever add such a feature, we'd be better off adding new columns > with a different name, just to avoid confusion over what's supposed to > be there. (For example: extant pg_dump scripts for user-defined types > will try to load wrong values into those columns if given a chance. So you know some place that actually uses the values from these columns ? Or is it just that we have told users long enough to make them same as typinput/typoutput ? > We *must* use new names for those slots in CREATE TYPE to avoid that > pitfall, and so we might as well change the system column name too.) Can't we just add a warning when typinput==typreceive or typoutput==typsend, or just plain refuse to make them equal and force people to create another function binding even if they are. The interim solution would be to set typreceive/typsend to NULL if they are the same as typinput/typoutput in CREATE TYPE. ------------------- Hannu
Hannu Krosing <hannu@tm.ee> writes:
> The interim solution would be to set typreceive/typsend to NULL if they
> are the same as typinput/typoutput in CREATE TYPE.
Which still puts you right back at square one. You might as well define
two new columns that will carry the function names for binary transport.
typsend/typreceive are hopelessly contaminated at this point, IMHO;
it'll be less work and less confusion to adopt other column names than
to try to reuse them just "because they're there".
regards, tom lane
On Tue, 2002-07-16 at 11:44, Tom Lane wrote: > Hannu Krosing <hannu@tm.ee> writes: > > The interim solution would be to set typreceive/typsend to NULL if they > > are the same as typinput/typoutput in CREATE TYPE. > > Which still puts you right back at square one. You might as well define > two new columns that will carry the function names for binary transport. Ok, but could this be then rename instead of removing the columns - it will be roughly the same amount of work going through all the places that touch pg_type. I'd even guess that renaming is _less_ work.. > typsend/typreceive are hopelessly contaminated at this point, IMHO; > it'll be less work and less confusion to adopt other column names than > to try to reuse them just "because they're there". ----------- Hannu