| From: | "Greg Burd" <greg(at)burd(dot)me> |
|---|---|
| To: | "Michael Paquier" <michael(at)paquier(dot)xyz>, "Bharath Rupireddy" <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
| Cc: | "Yugo Nagata" <nagata(at)sraoss(dot)co(dot)jp>, "PostgreSQL Hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Support for 8-byte TOAST values, round two |
| Date: | 2026-09-09 17:14:54 |
| Message-ID: | e971c02b-3472-4f94-9259-a0c70675206e@app.fastmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Correction to my last message, since I was clearly under-caffeinated or
rushed to get it sent. Not AI/LLM-slop this time HUMAN-slop. ;-P
I wrote:
> I tried, but couldn't reproduce the concern in practice.
That should say the concern does reproduce. Robert's worry was that some
tuples storable today would not be storable at all once the TOAST pointer
gets wider, and that is what the table right below that sentence shows. At
370 text columns set STORAGE EXTERNAL, oid stores the row and oid8 fails
with "row is too big: size 8824, maximum size 8160". The ceiling on
out-of-line attributes per row drops from about 453 to about 366.
Doesn't change where I land, still +1 on the series, and I think this is
the one cost that deserves a sentence in the docs next to the reloption.
best.
-greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | best xmg | 2026-09-09 17:18:58 | Hash a ScalarArrayOpExpr whose array is fixed for one execution |
| Previous Message | Bharath Rupireddy | 2026-09-09 17:13:43 | Re: Support for 8-byte TOAST values, round two |