Re: 32bit OID wrap around concerns - Mailing list pgsql-hackers

From Tom Lane
Subject Re: 32bit OID wrap around concerns
Date
Msg-id 10302.1425328732@sss.pgh.pa.us
Whole thread Raw
In response to Re: 32bit OID wrap around concerns  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: 32bit OID wrap around concerns  (Qingqing Zhou <zhouqq.postgres@gmail.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Qingqing Zhou wrote:
>> Do we think above scenario is something we shall worry about? Especially
>> for large databases.

> IMO in theory it sucks that toast values use the shared OID generator,
> though in practice I have never seen a problem due to that.  Often,
> toast value creation is interleaved across several tables, so the shared
> generator does not have to skip too many values at once each time.

Yeah, I was just explaining that to some Salesforce colleagues.  The fact
that we use a single shared OID generator (and not one per table) greatly
reduces the risk of long runs of consecutively-assigned OIDs in any one
table.

There is an issue if you do a dump and restore: the toast OIDs used in any
one table will be consecutive after that, because we load all the data for
each table sequentially.  It might be worth tweaking the generation rules
to try to avoid that scenario.  Still, there's not been any field
complaints indicating that this is a problem.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Weirdly pesimistic estimates in optimizer
Next
From: Kevin Grittner
Date:
Subject: Re: Idea: closing the loop for "pg_ctl reload"