Gregory Stark <stark@enterprisedb.com> wrote:
> The hoped for gain here is that vacuum finds fewer pages with tuples that
> exceed vacuum_freeze_min_age? That seems useful though vacuum is still going
> to have to read every page and I suspect most of the writes pertain to dead
> tuples, not freezing tuples.
Yes. VACUUM makes dirty pages only for freezing exceeded tuples in
particular cases and I think we can reduce the writes by keeping the
number of unfrozen tuples low.
There are three additional costs in FREEZE. 1. CPU cost for changing the xids of target tuples. 2. Writes cost for WAL
entriesof FREEZE (log_heap_freeze). 3. Writes cost for newly created dirty pages.
I did additional freezing in the following two cases. We'll have created
dirty buffers and WAL entries for required operations then, so that I think
the additional costs of 2 and 3 are ignorable, though 1 still affects us.
| - There are another tuple to be frozen in the same page.
| - There are another dead tuples in the same page.
| Freezing is delayed until the heap vacuum phase.
> This strikes me as something that will be more useful once we have the DSM
> especially if it ends up including a frozen map. Once we have the DSM vacuum
> will no longer be visiting every page, so it will be much easier for pages to
> get quite old and only be caught by a vacuum freeze. The less i/o that vacuum
> freeze has to do the better. If we get a freeze map then agressive freezing
> would help keep pages out of that map so they never need to be vacuumed just
> to freeze the tuples in them.
Yeah, I was planning to 2 bits/page DSM exactly for the purpose. One of the
bits means to-be-vacuumed and another means to-be-frozen. It helps us avoid
full scanning of the pages for XID wraparound vacuums, but DSM should be more
reliable and not lost any information. I made an attempt to accomplish it
in DSM, but I understand the need to demonstrate it works as designed to you.
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
