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.0106071332360.781-100000@sdf.lonestar.org обсуждение исходный текст |
Ответ на | Re: maximum number of rows in table - what about oid limits? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: maximum number of rows in table - what about oid limits?
Re: maximum number of rows in table - what about oid limits? |
Список | pgsql-sql |
Besides compatibility, what breaks when you make OIDs/Txn IDs INT8s? Maybe there should be a minor fork called Postgres64 which does this for those needing large tables. Jon johnnyb6@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org On Wed, 6 Jun 2001, Tom Lane wrote: > "Josh Berkus" <josh@agliodbs.com> writes: > > Given this, why bother with system-generated OIDs on user rows at all? > > Why not simply reserve the OIDs for the system tables? > > An option to not generate OIDs unless requested (on a table-by-table > basis) has been discussed. It seems like a fine near-term solution > to me. 8-byte OIDs are a longer-term solution, because they'll break > a lot of things (including clients...) > > >> This is certainly not ideal, but it's not nearly as big a problem as > >> transaction ID wraparound. You can live with it, whereas right now > >> xact ID wraparound is catastrophic. That we gotta work on, soon. > > > Nothing like reassuring us commercial DB users, Tom. :-P > > Can you describe what you're talking about? > > It's in the archives: after 4G transactions, your database curls up > and dies. When your pg_log starts to approach 1Gbyte (2 bits per > transaction) you'd better plan on dump/initdb/reload. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly >
В списке pgsql-sql по дате отправления: