"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> That would make the file creation and unlink just under half the load.
Worst possible case :-( ... means that we wouldn't get much improvement
without addressing both aspects.
It strikes me however that this does put some urgency into the question
of how much per-relation FSM is going to cost us. For short-lived temp
tables the FSM is never going to have any usefulness at all, but in the
current HEAD code it'll double the create/unlink load.
Heikki, would it be reasonable to fix things so that a nonexistent FSM
fork is semantically the same as an empty one, and not create FSM until
there's actually something to put in it?
regards, tom lane
