Re: Using per-transaction memory contexts for storing decoded tuples
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2024-09-19T03:55:15Z
Lists: pgsql-hackers
On Thu, Sep 19, 2024 at 6:46 AM David Rowley <dgrowleyml@gmail.com> wrote: > > On Thu, 19 Sept 2024 at 11:54, Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > I've done some benchmark tests for three different code bases with > > different test cases. In short, reducing the generation memory context > > block size to 8kB seems to be promising; it mitigates the problem > > while keeping a similar performance. > > Did you try any sizes between 8KB and 8MB? 1000x reduction seems > quite large a jump. There is additional overhead from having more > blocks. It means more malloc() work and more free() work when deleting > a context. It would be nice to see some numbers with all powers of 2 > between 8KB and 8MB. I imagine the returns are diminishing as the > block size is reduced further. > Good idea. > Another alternative idea would be to defragment transactions with a > large number of changes after they grow to some predefined size. > Defragmentation would just be a matter of performing > palloc/memcpy/pfree for each change. If that's all done at once, all > the changes for that transaction would be contiguous in memory. If > you're smart about what the trigger point is for performing the > defragmentation then I imagine there's not much risk of performance > regression for the general case. For example, you might only want to > trigger it when MemoryContextMemAllocated() for the generation context > exceeds logical_decoding_work_mem by some factor and only do it for > transactions where the size of the changes exceeds some threshold. > After collecting the changes that exceed 'logical_decoding_work_mem', one can choose to stream the transaction and free the changes to avoid hitting this problem, however, we can use that or some other constant to decide the point of defragmentation. The other point we need to think in this idea is whether we actually need any defragmentation at all. This will depend on whether there are concurrent transactions being decoded. This would require benchmarking to see the performance impact. -- With Regards, Amit Kapila.
Commits
-
Reduce memory block size for decoded tuple storage to 8kB.
- 1b9b6cc3456b 18.0 landed
- eef9cc4dc28f 17.1 landed
- 05e982cdc4df 16.5 landed
- 4a675f31868a 15.9 landed
- 5c1ed0a51681 14.14 landed
- cb988b04d063 13.17 landed
- 53fa68b3bc3a 12.21 landed
-
Generational memory allocator
- a4ccc1cef5a0 11.0 cited