>I wonder how hard it would be to hack up a table access method that is
just a copy of heap where HEAP_INSERT_SKIP_FSM is always set...
Update: I think this actually works. It's awful because I just copied the
entire builtin heap code into an extension and then renamed a few functions
so they don'
I'm experimenting with that right now. Setting storage to MAIN appears to
be counterproductive, whereas EXTERNAL with toast_tuple_target = 128 is
definitely an improvement. In theory, this configuration might eliminate
the problem, but due to the toast_tuple_target bug (
https://www.postgresql.org/
If you have no updates or deletes, then I would wonder about setting
fillfactor LOWER such that new rows are less likely to find a gap that is
acceptable. Depending how/when you use the json, lowering
toast_tuple_target may be appropriate to store (nearly?) all out of line
and making the data store
This is on version 12.5. The usage pattern is inserts only, no updates or
deletes at all. Hence, fillfactor is set to 100.
It just seems extremely unfortunate in this particular case that Postgres
goes to all the trouble of tetris-ing new tuples into existing pages, only
to cripple performance in
What version are you using? What is your usage pattern for
insert/update/deletes? If sometimes the JSON data gets too big and the data
is moved from in-line storage to TOASTED, then that would be opening up
gaps. Or if you are doing deletes. Perhaps adjusting your fillfactor
and/or TOAST_TUPLE_TARG
