Re: The vacuum-ignore-vacuum patch

From: Hannu Krosing <hannu(at)skype(dot)net>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: The vacuum-ignore-vacuum patch
Date: 2006-07-28 00:08:08
Message-ID: 1154045288.2908.26.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Ühel kenal päeval, N, 2006-07-27 kell 19:29, kirjutas Alvaro Herrera:

>
> We could either add it anew, beside nonInVacuumXmin, or replace
> nonInVacuumXmin. The difference will be whether we will have something
> to be used to vacuum shared relations or not. I think in general,
> shared relations are not vacuumed much so it shouldn't be too much of a
> problem if we leave them to be vacuumed with the regular, all-databases,
> include-vacuum Xmin.

Yes. I don't think that vacuuming shared relations will ever be a
significant performance concern.

> The other POV is that we don't really care about long-running
> transaction in other databases unless they are lazy vacuum, a case which
> is appropiately covered by the patch as it currently stands. This seems
> to be the POV that Hannu takes: the only long-running transactions he
> cares about are lazy vacuums.

Yes. The original target audience of this patch are users running 24/7
OLTP databases with big slow changing tables and small fast-changing
tables which need to stay small even at the time when the big ones are
vacuumed.

The other possible transactions which _could_ possibly be ignored while
VACUUMING are those from ANALYSE and non-lazy VACUUMs.

I don't care about them as:

ANALYSE is relatively fast, even on huge tables, and thus can be
ignored.

If you do run VACUUM FULL on anything bigger than a few thousand
lines then you are not running a 24/7 OLTP database anyway.

I also can't see a usecase for OLTP database where VACUUM FREEZE is
required.

Maybe we could also start ignoring the transactions that are running the
new CONCURRENT CREATE INDEX command, as it also runs inside its own
transaction(s) which can't possibly touch the tuples in the table being
vacuumed as it locks out VACUUM on the indexed table.

That would probably be quite easy to do by just having CONCURRENT CREATE
INDEX also mark its transactions as ignorable by VACUUM. Maybe the
variable name for that (proc->inVacuum) needs to be changed to something
like trxSafeToIgnoreByVacuum.

--
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia

Skype me: callto:hkrosing
Get Skype for free: http://www.skype.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-07-28 00:34:20 Re: The vacuum-ignore-vacuum patch
Previous Message Alvaro Herrera 2006-07-27 23:29:14 Re: The vacuum-ignore-vacuum patch

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2006-07-28 00:34:20 Re: The vacuum-ignore-vacuum patch
Previous Message Alvaro Herrera 2006-07-27 23:29:14 Re: The vacuum-ignore-vacuum patch