On Tue, Mar 12, 2024 at 6:41 AM David Rowley <dgrowleyml@gmail.com> wrote:
> Thanks for trying this out. I didn't check if the performance was
> susceptible to the memory size before the reset. It certainly would
> be once the allocation crosses some critical threshold of CPU cache
> size, but probably it will also be to some extent regarding the number
> of actual mallocs that are required underneath.
I neglected to mention it, but the numbers I chose did have the L2/L3
cache in mind, but the reset frequency didn't seem to make much
difference.
> I see there's some discussion of bump in [1]. Do you still have a
> valid use case for bump for performance/memory usage reasons?
Yeah, that was part of my motivation for helping test, although my
interest is in saving memory in cases of lots of small allocations. It
might help if I make this a little more concrete, so I wrote a
quick-and-dirty function to measure the bytes used by the proposed TID
store and the vacuum's current array.
Using bitmaps really shines with a high number of offsets per block,
e.g. with about a million sequential blocks, and 49 offsets per block
(last parameter is a bound):
select * from tidstore_memory(0,1*1001*1000, 1,50);
array_mem | ts_mem
-----------+----------
294294000 | 42008576
The break-even point with this scenario is around 7 offsets per block:
select * from tidstore_memory(0,1*1001*1000, 1,8);
array_mem | ts_mem
-----------+----------
42042000 | 42008576
Below that, the array gets smaller, but the bitmap just has more empty
space. Here, 8 million bytes are used by the chunk header in bitmap
allocations, so the bump context would help there (I haven't actually
tried). Of course, the best allocation is no allocation at all, and I
have a draft patch to store up to 3 offsets in the last-level node's
pointer array, so for 2 or 3 offsets per block we're smaller than the
array again:
select * from tidstore_memory(0,1*1001*1000, 1,4);
array_mem | ts_mem
-----------+---------
18018000 | 8462336
Sequential blocks are not the worst case scenario for memory use, but
this gives an idea of what's involved. So, with aset, on average I
still expect to use quite a bit less memory, with some corner cases
that use more. The bump context would be some extra insurance to
reduce those corner cases, where there are a large number of blocks in
play.
