On Thu, 15 Sept 2022 at 04:04, Aleksander Alekseev <aleksan...@timescale.com> wrote: > 1. Forbid setting toast_tuple_target < TOAST_TUPLE_THRESHOLD > 2. Consider using something like RelationGetToastTupleTarget(rel, > TOAST_TUPLE_THRESHOLD) in heapam.c:2250, heapam.c:3625 and > rewriteheap.c:636 and modify the documentation accordingly. > 3. Add a separate user-defined table setting toast_tuple_threshold > similar to toast_tuple_target. > > Thoughts?
There was some discussion on this problem in [1]. The problem with #2 is that if you look at heapam_relation_needs_toast_table(), it only decides if the toast table should be created based on (tuple_length > TOAST_TUPLE_THRESHOLD). So if you were to change the logic as you describe for #2 then there might not be a toast table during an INSERT/UPDATE. The only way to fix that would be to ensure that we reconsider if we should create a toast table or not when someone changes the toast_tuple_target reloption. That can't be done under ShareUpdateExclusiveLock, so we'd need to obtain an AccessExclusiveLock instead when changing the toast_tuple_target reloption. That might upset some people. The general direction of [1] was to just increase the minimum setting to TOAST_TUPLE_THRESHOLD, but there were some concerns about breaking pg_dump as we'd have to error if someone does ALTER TABLE to set the toast_tuple_target reloption lower than the newly defined minimum value. I don't quite follow you on #3. If there's no toast table we can't toast. David [1] https://www.postgresql.org/message-id/20190403063759.gf3...@paquier.xyz