From: | David Geier <geidav(dot)pg(at)gmail(dot)com> |
---|---|
To: | Melanie Plageman <melanieplageman(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: Eliminate redundant tuple visibility check in vacuum |
Date: | 2023-08-29 09:07:35 |
Message-ID: | 71d50e04-ae55-8965-2804-30a9bc0d2e0a@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Melanie,
On 8/29/23 01:49, Melanie Plageman wrote:
> While working on a set of patches to combine the freeze and visibility
> map WAL records into the prune record, I wrote the attached patches
> reusing the tuple visibility information collected in heap_page_prune()
> back in lazy_scan_prune().
>
> heap_page_prune() collects the HTSV_Result for every tuple on a page
> and saves it in an array used by heap_prune_chain(). If we make that
> array available to lazy_scan_prune(), it can use it when collecting
> stats for vacuum and determining whether or not to freeze tuples.
> This avoids calling HeapTupleSatisfiesVacuum() again on every tuple in
> the page.
>
> It also gets rid of the retry loop in lazy_scan_prune().
How did you test this change?
Could you measure any performance difference?
If so could you provide your test case?
--
David Geier
(ServiceNow)
From | Date | Subject | |
---|---|---|---|
Next Message | Etsuro Fujita | 2023-08-29 09:08:04 | Re: Missing comments/docs about custom scan path |
Previous Message | Kyotaro Horiguchi | 2023-08-29 08:56:15 | Standardize spelling of "power of two" |