| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Qingqing Zhou <zhouqq(dot)postgres(at)gmail(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: 32bit OID wrap around concerns |
| Date: | 2015-03-02 20:15:14 |
| Message-ID: | 20150302201514.GG3291@alvh.no-ip.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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 in use values of its own.
> 2. These by-passed oids are actually usable by other toast indices, but are
> wasted. This can lead to further aggravated OID wrap around.
>
> 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.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2015-03-02 20:15:22 | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0 |
| Previous Message | Qingqing Zhou | 2015-03-02 20:04:23 | 32bit OID wrap around concerns |