Re: maximum number of rows in table - what about oid limits?
От | Jonathan Bartlett |
---|---|
Тема | Re: maximum number of rows in table - what about oid limits? |
Дата | |
Msg-id | Pine.LNX.4.21.0106081740570.30360-100000@sdf.lonestar.org обсуждение исходный текст |
Ответ на | Re: maximum number of rows in table - what about oid limits? ("Josh Berkus" <josh@agliodbs.com>) |
Ответы |
Re: maximum number of rows in table - what about oid limits?
|
Список | 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
В списке pgsql-sql по дате отправления: