Re: OIDs as keys

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, daniel alvarez <d-alvarez(at)gmx(dot)de>, Richard Huxton <dev(at)archonet(dot)com>, PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: OIDs as keys
Date: 2003-03-07 01:50:36
Message-ID: 200303070150.h271oaW02436@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Neil Conway wrote:
> On Thu, 2003-03-06 at 16:13, Bruce Momjian wrote:
> > It would be good to somehow SET the use_oids GUC value on restore start,
> > and just use SET when the table is different than the default, but then
> > there is no mechanism to do that when you restore a single table.
>
> What if the default value changes?
>
> IMHO, running a SET per CREATE TABLE isn't too ugly...

Not ugly, but a little noisy. However, my idea of having a single SET
at the top is never going to work, so I don't have a better idea.

The killer for me is that you are never going to know the GUC default
when you are loading, so we are _always_ going to have that SET for each
table.

I suppose we could set the default to off, and set it ON in the dump
only when we want OID. If they set GUC to on, they will get oid's from
the load, but it will cut down on the cruft and over time, they will
only have the SET for cases where they really want an oid.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Aspire Something 2003-03-07 05:33:14 Re: New Interface for Win
Previous Message Neil Conway 2003-03-07 00:47:52 Re: [COMMITTERS] pgsql-server/ /configure /configure.in rc/incl ...