Hi,
Andres Freund wrote 2021-05-31 00:07:
Hi,
On 2021-05-30 03:10:26 +0300, Yura Sokolov wrote:
While this result is not directly applied to stock PostgreSQL, I
believe
page compression is important for full_page_writes with
wal_compression
enabled. And probably when PostgreSQL is used on filesystem with
compression enabled (ZFS?).
I don't think the former is relevant, because the hole is skipped in
wal page
compression (at some cost).
Ah, forgot about. Yep, you are right.
Therefore I propose clearing page's empty space with zero in
PageRepairFragmentation, PageIndexMultiDelete, PageIndexTupleDelete
and
PageIndexTupleDeleteNoCompact.
Sorry, didn't measure impact on raw performance yet.
I'm worried that this might cause O(n^2) behaviour in some cases, by
repeatedly memset'ing the same mostly already zeroed space to 0. Why do
we
ever need to do memset_hole() instead of accurately just zeroing out
the space
that was just vacated?
It is done exactly this way: memset_hole accepts "old_pd_upper" and
cleans between
old and new one.
regards,
Yura
