Re: Lowering the ever-growing heap->pd_lower
От | Matthias van de Meent |
---|---|
Тема | Re: Lowering the ever-growing heap->pd_lower |
Дата | |
Msg-id | CAEze2Wios_LkJ8o9ZAhS_g5YA7T9RZnsy6VXcnODbvZ-nQXhsA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Lowering the ever-growing heap->pd_lower (Matthias van de Meent <boekewurm+postgres@gmail.com>) |
Ответы |
Re: Lowering the ever-growing heap->pd_lower
|
Список | pgsql-hackers |
On Mon, 3 May 2021 at 16:39, Matthias van de Meent <boekewurm+postgres@gmail.com> wrote: > I am planning on fixing this patch sometime > before the next commit fest so that we can truncate the LP array > during hot pruning as well, instead of only doing so in the 2nd VACUUM > pass. PFA the updated version of this patch. Apart from adding line pointer truncation in PageRepairFragmentation (as in the earlier patches), I also altered PageTruncateLinePointerArray to clean up all trailing line pointers, even if it was the last item on the page. This means that for 32-bit systems, pages that have once had tuples (but have been cleared since) can now be used again for MaxHeapTupleSize insertions. Without this patch, an emptied page would always have at least one line pointer left, which equates to MaxHeapTupleSize actual free space, but PageGetFreeSpace always subtracts sizeof(ItemIdData), leaving the perceived free space as reported to the FSM less than MaxHeapTupleSize if the page has any line pointers. For 64-bit systems, this is not as much of a problem, because MaxHeapTupleSize is 4 bytes smaller on those systems, which leaves us with 1 line pointer as margin for the FSM to recognise the page as free enough for one MaxHeapTupleSize item. With regards, Matthias van de Meent
Вложения
В списке pgsql-hackers по дате отправления: