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
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 |
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 |