| From: | Hannu Krosing <hannuk(at)google(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Support for 8-byte TOAST values, round two |
| Date: | 2026-07-31 10:58:27 |
| Message-ID: | CAMT0RQTcMAZpsB-beEfKC79Dpft-C7TpMYF=CUp5P5LQOhXcGw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Jul 31, 2026 at 4:37 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Thu, Jul 30, 2026 at 01:16:36PM +0200, Hannu Krosing wrote:
> > Have you compared the index sizes of OID and 8-byte ID ?
>
> Please do not top-post. This breaks the logical flow of the community
> thread. Please see the following about bottom-posting:
> https://en.wikipedia.org/wiki/Posting_style#Bottom-posting
Sorry about that, I need to get an email client that makes it easier
to see when I'm about to do that :p
> > It is possible, that they are of the same size because of alignment, so
> > there would not be any difference in size.
>
> I suspect that the size is the same due to 8-byte alignment (not done
> a measurement on that with a fixed loading pattern).
I ran a quick test and at least on x64 this is the case indeed:
hannuk=# create table oid_vs_bigint(id oid primary key, int8 bigint unique);
CREATE TABLE
hannuk=# insert into oid_vs_bigint select i, i from
generate_series(1,100000) g(i);
INSERT 0 100000
hannuk=# select indexrelid::regclass, pg_relation_size(indexrelid)
from pg_index where indrelid = 'oid_vs_bigint'::regclass;
indexrelid │ pg_relation_size
────────────────────────┼──────────────────
oid_vs_bigint_pkey │ 2260992
oid_vs_bigint_int8_key │ 2260992
(2 rows)
So, it's not slower because of size, but it's not faster either.
> Just please note
> that the OID8 behavior is available on an opt-in as a reloption, with
> OID still being the default. So there is no impact by default,
> neither is there an impact across upgrades. A relation set with an
> OID8 is preserved across pg_upgrade moving forward to newer versions,
> of course.
Yes, any new TOAST types should live alongside the existing one and
not try to replace them in one go.
My Direct Toast design does the same: either a reloption or a global
GUC for selecting on write and automatic selection by the VARATT type
on reads.
In the case of Direct Toast this also means that both TOAST types can
coexist in the same table for both the main heap and TOAST storage,
and you can switch back and forth at any time, for example, switching
to direct only when you run into the 4B OID limit.
For OID8 I guess you can still have it, but you will need to create a
second oid8 toast table because the toast table format changed in
incompatible ways.
----
Hannu
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Matthias van de Meent | 2026-07-31 11:10:14 | Re: Support for 8-byte TOAST values, round two |
| Previous Message | Andrey Borodin | 2026-07-31 10:23:51 | Re: Streaming replication and WAL archive interactions |