Re: Reducing System Allocator Thrashing of ExecutorState to Alleviate FDW-related Performance Degradations

Hi,

On 2023-02-17 09:52:01 -0800, Andres Freund wrote:
> On 2023-02-17 17:26:20 +1300, David Rowley wrote:
> Random note:
>
> I wonder if we should having a bitmap (in an int) in front of aset's
> freelist. In a lot of cases we incur plenty cache misses, just to find the
> freelist bucket empty.

Two somewhat related thoughts:

1) We should move AllocBlockData->freeptr into AllocSetContext. It's only ever
used for the block at the head of ->blocks.

We completely unnecessarily incur more cache line misses due to this (and
waste a tiny bit of space).

2) We should introduce an API mcxt.c API to perform allocations that the
caller promises not to individually free. We've talked a bunch about
introducing a bump allocator memory context, but that requires using
dedicated memory contexts, which incurs noticable space overhead, whereas
just having a separate function call for the existing memory contexts
doesn't have that issue.

For aset.c we should just allocate from set->freeptr, without going through
the freelist. Obviously we'd not round up to a power of 2. And likely, at
least outside of assert builds, we should not have a chunk header.

Greetings,

Andres Freund