Re: maximum number of rows in table - what about oid limits?

From: Jonathan Bartlett <johnnyb6(at)sdf(dot)lonestar(dot)org>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-sql(at)postgresql(dot)org
Subject: Re: maximum number of rows in table - what about oid limits?
Date: 2001-06-08 17:48:06
Message-ID: Pine.LNX.4.21.0106081740570.30360-100000@sdf.lonestar.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-sql

> Actually, I'm doing this with one of my applications. Rather than using
> the (problematic) OID, I simply established an independant sequence
> ('universal_sq') and used that as the primary key for all of my
> important data tables. So long as the total records in these tables
> stays < 2.4 billion, I'm doing fine. Nothing in PostgreSQL prevents you
> from using a single independent sequence as the key for multiple tables.

The nice thing about OIDs is that if you ever need to merge rows, you
could make a function that searched all OID-type parameters and change the
old reference to the new one.

> If you are concerned about having > 2.4 billion recs, then perhaps it's
> time to hack an INT8 sequence functionality. I think that adding INT8
> sequences to the PostgreSQL database would be a *lot* easier than
> modifying OID functionality. In fact, if it matters to you, why not pay
> for it to get done?

Were I doing PostgreSQL for a business, I most assuredly would. However,
I am currently just toying around with creating a common set of base
tables that would be useful in almost any application, taking advantage of
PostgreSQL's specific capabilities. However, I asked the question because
if the only real problem is compatibility, I might be able to do it
myself (or maybe not).

> P.S. A lot of these concerns affect only developers with high-traffic
> web applications and similar. For example, in my small business
> software, it will take <> 1 million days to exhaust the TXN register.
> Not something I need to worry about.

Agreed, but if people are going to take PostgreSQL seriously, then some
of the top limits need to be expanded.

> Is there some good way that we can "vote with our pocketbooks" for
> various development issues in the PostgreSQL to-do list, short of hiring
> a C programmer ourselves? I, for one, am desperately eager for real
> stored procedures, and could get my clients to contribute toward the
> development, but not more than 4 figures ...

You could probably find a college student to do whatever you wanted for a
grand.

Out of curiosity, what do you mean by "Real Stored Procedures"?

Jon

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Alex Pilosov 2001-06-08 17:58:31 Re: RE: VARCHAR to CIDR type cast
Previous Message Rene Pijlman 2001-06-08 17:34:34 Re: very big problem with NULL

Browse pgsql-sql by date

  From Date Subject
Next Message Josh Berkus 2001-06-08 18:15:26 Re: maximum number of rows in table - what about oid limits?
Previous Message Josh Berkus 2001-06-08 16:53:16 Re: [HACKERS] Re: behavior of ' = NULL' vs. MySQL vs. Standards