|From:||John Naylor <jcnaylor(at)gmail(dot)com>|
|Subject:||WIP: Avoid creation of the free space map for small tables|
|Views:||Raw Message | Whole Thread | Download mbox|
A while back, Robert Haas noticed that the space taken up by very
small tables is dominated by the FSM . Tom suggested that we could
prevent creation of the FSM until the heap has reached a certain
threshold size . Attached is a WIP patch to implement that. I've
also attached a SQL script to demonstrate the change in behavior for
The behavior that allows the simplest implementation I thought of is as follows:
-The FSM isn't created if the heap has fewer than 10 blocks (or
whatever). If the last known good block has insufficient space, try
every block before extending the heap.
-If a heap with a FSM is truncated back to below the threshold, the
FSM stays around and can be used as usual.
-If the heap tuples are all deleted, the FSM stays but has no leaf
blocks (same as on master). Although it exists, it won't be
re-extended until the heap re-passes the threshold.
-For normal mode, I taught fsm_set_and_search() to switch to a
non-extending buffer call, but the biggest missing piece is WAL
replay. I couldn't find a non-extending equivalent of
XLogReadBufferExtended(), so I might have to create one.
-There'll need to be some performance testing to make sure there's no
regression, and to choose a good value for the threshold. I'll look
into that, but if anyone has any ideas for tests, that'll help this
-A possible TODO item is to teach pg_upgrade not to link FSMs for
small heaps. I haven't look into the feasibility of that, however.
-RelationGetBufferForTuple() now has two boolean variables that mean
"don't use the FSM", but with different behaviors. To avoid confusion,
I've renamed use_fsm to always_extend and revised the commentary
-I've only implemented this for heaps, because indexes (at least
B-tree) don't seem to be as eager to create a FSM. I haven't looked at
the code, however.
I'll add this to the November commitfest.
|Next Message||Jonathan S. Katz||2018-10-05 19:28:41||Re: Postgres 11 release notes|
|Previous Message||Andres Freund||2018-10-05 17:29:55||Re: Skylake-S warning|