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
On Mon, Mar 2, 2015 at 12:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
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.
With these consecutive oids, the aggravated oid
One scenario is to use an oid to identify a toast value. As the oid
generation is mono increased within a database instance, it can gets wrap
around after 2^32 generations. After that:
1. GetNewOidWithIndex() could gets unbounded performance as it needs to by
pass already in use values of its own.
Qingqing Zhou wrote:
One scenario is to use an oid to identify a toast value. As the oid
generation is mono increased within a database instance, it can gets wrap
around after 2^32 generations. After that:
1. GetNewOidWithIndex() could gets unbounded performance as it needs to by
pass already
