Re: Unexpected page allocation behavior on insert-only tables

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sun, May 30, 2010 at 10:42 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> pretty clear what is going on. See the logic in
>> RelationGetBufferForTuple, and note that at no time do we have any FSM
>> data for the bid table:

> Is this because, in the absence of updates or deletes, we never vacuum it?

Right.

>> 4. Now, all the backends again decide to try to insert into the last
>> available block. So everybody jams into the partly-filled block 10,
>> until it gets filled.

> Would it be (a) feasible and (b) useful to inject some entropy into this step?

Maybe, but at least in this case, the insert rate is not fast enough
that contention for the block is worth worrying about. IMO this isn't
the part of the cycle that needs fixed.

I guess another path to a fix might be to allow the backends to record
new pages in the FSM immediately at creation. That might result in more
insert contention, but it'd avoid losing track of the free space
permanently, which is what is happening here (unless something happens
to cause a vacuum). One reason the current code doesn't do that is that
the old in-memory FSM couldn't efficiently support retail insertion of
single-page data, but the new FSM code hasn't got a problem with that.

regards, tom lane