-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 oid index is
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 much for
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
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
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...
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.
Hmm ... within a
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 of OID?
I
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 pg_class where
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
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 excited
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,...}
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 they'd
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?
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 this
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
Tom Lane wrote:
Lamar Owen [EMAIL PROTECTED] writes:
snip
snip
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:
INSERT
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
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
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 to be the
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 Taylor [EMAIL PROTECTED] wrote regarding Re:
OID wraparound (was Re: [HACKERS] pg_depend) :
If OIDs are dropped a mechanism for retrieving the primary
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_description
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 don't
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)
If OIDs are dropped a mechanism for retrieving the primary key of
the
last insert would be greatly
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 that
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 don't
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. Especially
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
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 in
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
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 table
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
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,
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:
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 to hear
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: [HACKERS] pg_depend)
Lamar Owen [EMAIL PROTECTED] writes:
On Wednesday 18 July 2001
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
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 keep our
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 either,
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 to find
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 created by default.
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 wasn't
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
[EMAIL
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 optional.
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 commands
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, tom lane
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.
We've discussed it enough, it's time
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 one. :-)
--
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
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.
/01, 4:32:28 PM, Tom Lane [EMAIL PROTECTED] wrote regarding Re:
OID wraparound (was Re: [HACKERS] pg_depend) :
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
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
object to let
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, return
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
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 the
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, |
56 matches
Mail list logo
