Re: Aggressive freezing in lazy-vacuum

From: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
To: Gregory Stark <stark(at)enterprisedb(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Aggressive freezing in lazy-vacuum
Date: 2007-03-07 01:56:04
Message-ID: 20070307092455.5DF2.ITAGAKI.TAKAHIRO@oss.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches pgsql-performance

Gregory Stark <stark(at)enterprisedb(dot)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 entries of 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2007-03-07 02:10:17 Re: Bug: Buffer cache is not scan resistant
Previous Message Jim Nasby 2007-03-07 00:43:43 Re: Bug: Buffer cache is not scan resistant

Browse pgsql-patches by date

  From Date Subject
Next Message ITAGAKI Takahiro 2007-03-07 02:18:20 Re: Aggressive freezing in lazy-vacuum
Previous Message Joris Dobbelsteen 2007-03-06 21:54:50 Re: Auto creation of Partitions

Browse pgsql-performance by date

  From Date Subject
Next Message Merlin Moncure 2007-03-07 02:12:03 Re: compact flash disks?
Previous Message Paolo Negri 2007-03-06 23:25:58 problem with wrong query planning and ineffective statistics