| From: | Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Clear empty space in a page. |
| Date: | 2021-06-01 06:08:11 |
| Message-ID: | e574f566eedb39a06083168f976bdb57@postgrespro.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dilip Kumar | 2021-06-01 06:13:55 | Re: Decoding speculative insert with toast leaks memory |
| Previous Message | Dilip Kumar | 2021-06-01 05:30:49 | Re: Decoding speculative insert with toast leaks memory |