| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Clear empty space in a page. |
| Date: | 2021-05-30 21:07:12 |
| Message-ID: | 20210530210712.5mklwl4egotev3ir@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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).
> 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?
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-05-30 21:10:59 | Re: postgres_fdw batching vs. (re)creating the tuple slots |
| Previous Message | Andres Freund | 2021-05-30 20:58:31 | Re: postgres_fdw batching vs. (re)creating the tuple slots |