> -Original Message-
> Zeugswetter Andreas SB
>
> > As I mentioned already I'm implementing updatable cursors
> > in ODBC and have half done it. If OIDs would be optional
> > my trial loses its validity but I would never try another
> > implementation.
>
> But how can you do that ? The oi
On Thursday 19 July 2001 06:08, you wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> I think it should be off on user tables by default, but kept on system
> tables just for completeness. It could be added at table creation time
> or from ALTER TABLEL ADD. It seems we just use them too mu
Bruce Momjian <[EMAIL PROTECTED]> writes:
> What about moving the oid column out of the tuple header. This saves 4
> bytes in the header in cases where there is no oid on the table.
No it doesn't --- at least not on machines where MAXALIGN is eight
bytes.
I don't think this is worth the trouble
> As I mentioned already I'm implementing updatable cursors
> in ODBC and have half done it. If OIDs would be optional
> my trial loses its validity but I would never try another
> implementation.
But how can you do that ? The oid index is only created by
the dba for specific tables, thus your u
Tom mentioned what should be stored in the OID system column if no oid's
are in the table. He also mentioned that he doesn't want a
variable-length tuple header so will always have an oid system column.
What about moving the oid column out of the tuple header. This saves 4
bytes in the header i
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Could you use CTID instead of OID?
>
> > I am using both.
> > TIDs for fast access and OIDs for identification.
> > Unfortunately TIDs are transient and they aren't
> > that reliable as for identification.
>
>
Philip Warner <[EMAIL PROTECTED]> writes:
> At 00:00 19/07/01 -0400, Tom Lane wrote:
>> INSERT INTO foo ... RETURNING x,y,z,...
> That would have been me; at the time we also talked about
> UPDATE...RETURNING and Jan proposed allowing UPDATE...RETURNING
> {[Old.|New.]Attr,...}
Hm. I'm less exci
J-P wrote:
> > I need to create a new system table like pg_log to
> > implement a replication scheme. The big problem is
> how
> > I could get an OID for it, a unique OID that is
> > reserved for that table???
Hiroshi Inoue wrote:
>
>
> Do you need the following ?
>
> visco=# select oid from p
> Yes, nowhere near, and yes. Sequence objects require disk I/O to
> update; the OID counter essentially lives in shared memory, and can
> be bumped for the price of a spinlock access.
Sequences also cache values (32 afair) - ie one log record is required
for 32 nextval-s. Sequence' data file is
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Could you use CTID instead of OID?
> I am using both.
> TIDs for fast access and OIDs for identification.
> Unfortunately TIDs are transient and they aren't
> that reliable as for identification.
Hmm ... within a transaction I think
>>>Bruce Momjian said:
[...]
> > No, we won't, because OID wrap is an issue already for any long-uptime
> > installation. (64-bit XIDs are not a real practical answer either,
> > btw.)
>
> Have we had a wraparound yet?
Just for the record, I had an OID overflow on production database (most
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > As I mentioned already I'm implementing updatable cursors
> > in ODBC and have half done it. If OIDs would be optional
> > my trial loses its validity but I would never try another
> > implementation.
>
> Could you use CTID instead
At 00:00 19/07/01 -0400, Tom Lane wrote:
>that someone (maybe Larry R? I forget now) proposed before:
>
> INSERT INTO foo ... RETURNING x,y,z,...
>
That would have been me; at the time we also talked about
UPDATE...RETURNING and Jan proposed allowing UPDATE...RETURNING
{[Old.|New.]Attr,...
Tom Lane wrote:
>Lamar Owen <[EMAIL PROTECTED]> writes:
>
>>
>>
>
>
>
>Another possibility, given that any app using a feature like this is
>nonportable anyway, is to extend the INSERT statement along the lines
>that someone (maybe Larry R? I forget now) proposed before:
>
> INS
On Wednesday 18 July 2001 07:49 pm, Tom Lane wrote:
> I don't think we should discourage use of OIDs quite as vigorously
> as you propose ;-).
Just playing devil's advocate. As I said, I am one who is using OID's in a
client now but who is willing to forgo that feature for large-system
sta
On Thursday 19 July 2001 12:00 am, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > However, the utility of INSERT returning a unique identifier to the
> > inserted row needs to be addressed -- I would prefer it return the
> Another possibility, given that any app using a feature like
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> As I mentioned already I'm implementing updatable cursors
> in ODBC and have half done it. If OIDs would be optional
> my trial loses its validity but I would never try another
> implementation.
Could you use CTID instead of OID?
Lamar Owen <[EMAIL PROTECTED]> writes:
> However, the utility of INSERT returning a unique identifier to the
> inserted row needs to be addressed -- I would prefer it return the
> defined PRIMARY KEY value for the tuple just inserted, if a PRIMARY
> KEY is defined. If no PRIMARY KEY is defined, r
I wrote:
>
> Tom Lane wrote:
> >
> > Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > > I don't love current OIDs. However they have lived in PostgreSQL's
> > > world too long and few people have pointed out that there's no magic
> > > around OIDs. I agree to change OIDs to be per class but strongly
>> What's wrong with 64-bit oids (except extra 4bytes)?
> Portability, mostly.
Oh, there's one other small problem: breaking the on-the-wire protocol.
We send OIDs as column datatype identifiers, so an 8-byte-OID backend
would not interoperate with clients that didn't also think OID is 8
bytes.
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> What about pg_log? It will easily become a huge file. Currently the
> only solution is re-installing whole database, that is apparently
> unacceptable for very big installation like 1TB.
That's part of the XID wraparound issue, which is a separate
discus
From: Tom Lane <[EMAIL PROTECTED]>
Subject: OID wraparound (was Re: [HACKERS] pg_depend)
Date: Wed, 18 Jul 2001 13:52:45 -0400
Message-ID: <[EMAIL PROTECTED]>
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Yikes, I am not sure we are ready to make oids optional.
>
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > What do we do with other columns that need descriptions and don't have
> > oid column.
> >>
> >> Like what?
>
> > Depends what other system tables you are intending to remove oid's for?
>
> Nothing that requires a description ;-)
You are a sly on
Bruce Momjian <[EMAIL PROTECTED]> writes:
> What do we do with other columns that need descriptions and don't have
> oid column.
Like what?
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe command
Bruce Momjian <[EMAIL PROTECTED]> writes:
> What do we do with other columns that need descriptions and don't have
> oid column.
>>
>> Like what?
> Depends what other system tables you are intending to remove oid's for?
Nothing that requires a description ;-)
regards, t
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > I don't love current OIDs. However they have lived in PostgreSQL's
> > world too long and few people have pointed out that there's no magic
> > around OIDs. I agree to change OIDs to be per class but strongly
> > object to let OIDs
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > What do we do with other columns that need descriptions and don't have
> > oid column.
>
> Like what?
Depends what other system tables you are intending to remove oid's for?
--
Bruce Momjian| http://candle.pha.pa.us
[
"Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
> On Wed, Jul 18, 2001 at 04:06:28PM -0400, Tom Lane wrote:
>> My thought is to make OID generation optional on a per-table basis, and
>> disable it on system tables that don't need unique OIDs. (OID would
>> read as NULL on any row for which an OID
Bruce Momjian wrote:
>
> > > If you want to make oids optional on user tables,
> > > we can vote on that.
> >
> > Let's vote. I'm proposing optional oids for 2-3 years,
> > so you know how I'll vote -:)
>
> OK, we need to vote on whether Oid's are optional, and whether we can
> have them not crea
> >> I meant we use them in many cases to link entries, and in
> >> pg_description for descriptions and lots of other things
> >> that may use them in the future for system table use.
>
> pg_description is a point I hadn't thought about --- it uses OIDs
> to refer to pg_attribute entries. Howeve
Lamar Owen <[EMAIL PROTECTED]> writes:
> Now for a question: OID creation seems to be a low-overhead task. Is the
> creation of SERIAL PRIMARY KEY values as efficient? Or will we be shooting
> ourselves in the performance foot if frequently-accessed system tables go
> from OID usage to SERIAL
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Remember most pg_description comments are not on column but on functions
> and stuff. That attributenumber is not going to apply there.
Sure, it'd just be zero for non-column items.
regards, tom lane
--
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> I don't love current OIDs. However they have lived in PostgreSQL's
> world too long and few people have pointed out that there's no magic
> around OIDs. I agree to change OIDs to be per class but strongly
> object to let OIDs optional.
Uh ... what? I d
On Wed, Jul 18, 2001 at 04:06:28PM -0400, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Is the idea to make oid's optional, with them disabled by default on
> > user tables?
>
> My thought is to make OID generation optional on a per-table basis, and
> disable it on system tables
ot; <[EMAIL PROTECTED]>
Cc: "Lamar Owen" <[EMAIL PROTECTED]>; "Tom Lane"
<[EMAIL PROTECTED]>; "PostgreSQL-development"
<[EMAIL PROTECTED]>
Sent: Wednesday, July 18, 2001 5:06 PM
Subject: Re: OID wraparound (was Re: [HACKERS] pg_depend)
&g
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Remember most pg_description comments are not on column but on functions
> > and stuff. That attributenumber is not going to apply there.
>
> Sure, it'd just be zero for non-column items.
What do we do with other columns that need descriptions and
>> I meant we use them in many cases to link entries, and in
>> pg_description for descriptions and lots of other things
>> that may use them in the future for system table use.
pg_description is a point I hadn't thought about --- it uses OIDs
to refer to pg_attribute entries. However, pg_descri
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I think it should be off on user tables by default, but kept on system
> tables just for completeness.
Clearly, certain system tables *must* have OIDs --- pg_class, pg_type,
pg_operator, etc --- because we use those OIDs to refer to objects.
These are e
[trimmed cc:list]
On Wednesday 18 July 2001 17:09, Bruce Momjian wrote:
> OK, we need to vote on whether Oid's are optional, and whether we can
> have them not created by default.
[All the below IMHO]
OID's should be optional.
System tables that absolutely have to have OIDs may keep them.
No n
Larry Rosenman <[EMAIL PROTECTED]> writes:
> Maybe ctid needs to be documented better?
I think it's documented about as well as OID is, actually --- see
http://www.ca.postgresql.org/users-lounge/docs/7.1/postgres/sql-syntax-columns.html
which AFAIR is the only formal documentation of any of th
>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 7/18/01, 4:32:28 PM, Tom Lane <[EMAIL PROTECTED]> wrote regarding Re:
OID wraparound (was Re: [HACKERS] pg_depend) :
> Bruce Momjian
> OK, we need to vote on whether Oid's are optional,
> and whether we can have them not created by default.
Optional OIDs: YES
No OIDs by default: YES
> > > However, OID's keep our system tables together.
> >
> > How?! If we want to find function with oid X we query
> > pg_proc, if we want
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Also, without OID's, how do you fix EXACT duplicate records that happen
>> by accident?
> How about tid's? SELECT tid FROM tab1.
"SELECT ctid", actually, but that is still the fallback. (Actually
it always was --- OIDs aren't necessarily unique ei
> > If you want to make oids optional on user tables,
> > we can vote on that.
>
> Let's vote. I'm proposing optional oids for 2-3 years,
> so you know how I'll vote -:)
OK, we need to vote on whether Oid's are optional, and whether we can
have them not created by default.
>
> > However, OID's
> If you want to make oids optional on user tables,
> we can vote on that.
Let's vote. I'm proposing optional oids for 2-3 years,
so you know how I'll vote -:)
> However, OID's keep our system tables together.
How?! If we want to find function with oid X we query
pg_proc, if we want to find tab
> If OIDs are dropped a mechanism for retrieving the primary key of the
> last insert would be greatly appreciated. Heck, it would be useful
> now (rather than returning OID).
>
> I much prefer retrieving the sequence number after the insert than
> before insert where the insert uses it. Especi
> Also, without OID's, how do you fix EXACT duplicate records that happen
> by accident?
How about tid's? SELECT tid FROM tab1.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 8
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Is the idea to make oid's optional, with them disabled by default on
> > user tables?
>
> My thought is to make OID generation optional on a per-table basis, and
> disable it on system tables that don't need unique OIDs. (OID would
> read as NULL o
Also, without OID's, how do you fix EXACT duplicate records that happen
by accident?
LER
>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 7/18/01, 3:46:30 PM, Rod Taylo
On Wednesday 18 July 2001 16:06, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Is the idea to make oid's optional, with them disabled by default on
> > user tables?
> It remains to be debated exactly how users should control the choice for
> user tables, and which choice ought t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Is the idea to make oid's optional, with them disabled by default on
> user tables?
My thought is to make OID generation optional on a per-table basis, and
disable it on system tables that don't need unique OIDs. (OID would
read as NULL on any row for
t;Tom Lane" <[EMAIL PROTECTED]>
To: "Lamar Owen" <[EMAIL PROTECTED]>
Cc: "Bruce Momjian" <[EMAIL PROTECTED]>; "PostgreSQL-development"
<[EMAIL PROTECTED]>
Sent: Wednesday, July 18, 2001 4:30 PM
Subject: Re: OID wraparound (was Re: [HACKE
Lamar Owen <[EMAIL PROTECTED]> writes:
> On Wednesday 18 July 2001 16:06, Tom Lane wrote:
>> It remains to be debated exactly how users should control the choice for
>> user tables, and which choice ought to be the default. I don't have a
>> strong opinion about that either way, and am prepared t
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Yikes, I am not sure we are ready to make oids optional.
>
> We've discussed it enough, it's time to do it. I have an ulterior plan
> here: I want 7.2 not to have any limitations that prevent it from being
> used in a true 24x7, up-forever scenario
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > ... these two issues of ID wrap need to be addressed -- my gut feel is
> > that the reports of OID/XID wrap are going to skyrocket within 6 months as
> > bigger and bigger installations try out PostgreSQL/RHDB
>
> Yes, my thoughts exactly. We're tr
On Wednesday 18 July 2001 13:52, Tom Lane wrote:
> here: I want 7.2 not to have any limitations that prevent it from being
> used in a true 24x7, up-forever scenario. VACUUM lockouts are fixed
> now, or nearly. The other stumbling blocks for continuous runs are OID
Go for it, Tom. After the po
Lamar Owen <[EMAIL PROTECTED]> writes:
> ... these two issues of ID wrap need to be addressed -- my gut feel is
> that the reports of OID/XID wrap are going to skyrocket within 6 months as
> bigger and bigger installations try out PostgreSQL/RHDB
Yes, my thoughts exactly. We're trying to play
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yikes, I am not sure we are ready to make oids optional.
We've discussed it enough, it's time to do it. I have an ulterior plan
here: I want 7.2 not to have any limitations that prevent it from being
used in a true 24x7, up-forever scenario. VACUUM lo
58 matches
Mail list logo
