From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
Cc: | Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>, John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Lowering the ever-growing heap->pd_lower |
Date: | 2021-08-04 01:51:25 |
Message-ID: | CAH2-Wz=0vn06B8cYC5zcQAtDxJNgHjxgjv0hBcSkFC3wA4zuCw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Aug 3, 2021 at 12:27 PM Matthias van de Meent
<boekewurm+postgres(at)gmail(dot)com> wrote:
> This change makes it easier and more worthwile to implement a further
> optimization for the checkpointer and/or buffer manager to determine
> that 1.) this page is now empty, and that 2.) we can therefore write a
> specialized WAL record specifically tuned for empty pages instead of
> FPI records. No additional pages are changed, because each time the
> line pointer array is shrunk, we've already either marked dead tuples
> as unused (2nd phase vacuum) or removed HOT line pointers / truncated
> dead tuples to lp_dead line pointers (heap_page_prune).
We generate an FPI the first time a page is modified after a
checkpoint. The FPI consists of the page *after* it has been modified.
Presumably this optimization would need the heap page to be 100%
empty, so we're left with what seems to me to be a very narrow target
for optimization; something that is naturally rare.
A fully-empty page seems quite unlikely in the case of xl_heap_vacuum
records, and impossible in the case of xl_heap_prune records. Even
with all the patches, working together. Have I missed something?
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2021-08-04 03:17:30 | Re: Failed transaction statistics to measure the logical replication progress |
Previous Message | Thomas Munro | 2021-08-04 01:49:23 | Re: Commitfest overflow |