Alvaro Herrera <alvhe...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
