From: Tom Lane <tgl@sss.pgh.pa.us>
To: Natalie Wenz <nataliewenz@ebureau.com>
cc: pgsql-admin <pgsql-admin@postgresql.org>,
        "Joshua D. Drake" <jd@commandprompt.com>, david.g.johnston@gmail.com
Subject: Re: pg_toast oid limits
In-reply-to: <8B647628-89BE-43FE-B538-973BF85A79A9@ebureau.com>
References: <A88C1E63-DB62-43C6-B8EC-E78D07574690@ebureau.com>
 <24095.1477509777@sss.pgh.pa.us>
 <8B647628-89BE-43FE-B538-973BF85A79A9@ebureau.com>
Comments: In-reply-to Natalie Wenz <nataliewenz@ebureau.com>
	message dated "Wed, 26 Oct 2016 17:12:59 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <10801.1477521336.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 26 Oct 2016 18:35:36 -0400
Message-ID: <10802.1477521336@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-admin-owner@postgresql.org

Natalie Wenz <nataliewenz@ebureau.com> writes:
> I'm a little confused about the limit. Is it 4 billion oids for the whole=
 database, or just per table? I keep coming back to this line, from https:/=
/wiki.postgresql.org/wiki/TOAST :=20

Per table --- the problem is you need a unique 4-byte chunk_id for each
toasted field value.

> "If you exceed 4 billion of these rows across all tables (remember this i=
s a global shared wrapping counter), then the OID counter "wraps" which mig=
ht cause significant slowdown as you approach the 4B row limit."

Um.  That could use improvement, couldn't it.  The numbers are sourced
from a global counter, but as the counter wraps around it's possible for
the same number to be re-used in different toast tables.  You only start
to see a problem when the density of already-used numbers in a particular
toast table gets too high, so that the system has to spend a long time
searching for the next free number.

			regards, tom lane


--=20
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin