From: Gregory Stark <stark@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Pavan Deolasee <pavan.deolasee@gmail.com>
Cc: Pgsql Hackers <pgsql-hackers@postgresql.org>
Subject: Re: [PATCHES] VACUUM Improvements - WIP Patch
Date: Mon, 14 Jul 2008 19:24:14 +0100
Message-ID: <87bq10nx2p.fsf@oxford.xeocode.com> (raw)
In-Reply-To: <28739.1216058100@sss.pgh.pa.us>
References: <2e78013d0806092232h6ca15ffejcbcd24e88401308f@mail.gmail.com>
<21751.1215883933@sss.pgh.pa.us>
<2e78013d0807132050j16cdc558s4dc3f889371a937d@mail.gmail.com>
<8741.1216049025@sss.pgh.pa.us>
<87hcasmloh.fsf@oxford.xeocode.com>
<28739.1216058100@sss.pgh.pa.us>
"Tom Lane" <tgl@sss.pgh.pa.us> writes:
> Gregory Stark <stark@enterprisedb.com> writes:
>> I like the idea of only having to do a single pass through the table though.
>
> Well, that argument was already overstated: we're not re-reading all of
> the table now. Just the pages containing dead line pointers.
>
>> Couldn't Pavan's original plan still work and just not have other clients try
>> to remove dead line pointers?
>
> You could simply delay recycling of the really-truly-dead line pointers
> until the next VACUUM, I suppose. It's not clear how bad a
> line-pointer-bloat problem that might leave you with. (It would still
> require tracking whether the last vacuum had completed successfully.
> I note that any simple approach to that would foreclose ever doing
> partial-table vacuums, which is something I thought was on the table
> as soon as we had dead space mapping ability.)
Well there were three suggestions on how to track whether the last vacuum
committed or not. Keeping the last vacuum id in pg_class, keeping it per-page,
and keeping it per line pointer. ISTM either of the latter two would work with
partial table vacuums. Per line-pointer xids seemed excessively complicated to
me but per-page vacuum ids doesn't seem problematic.
I would definitely agree that partial-table vacuums are an essential part of
the future.
>> At least not unless they're also pruning the
>> page due to an insert or update anyways?
>
> Please stop pretending that this overhead will only be paid by
> insert/update. The current design for pruning does not work that way,
> and we do not have a better design available.
Well I'm not pretending. I guess there's something I'm missing here. I thought
we only pruned when we wanted to insert a new tuple and found not enough
space.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-patches@postgresql.org
Cc: stark@enterprisedb.com, tgl@sss.pgh.pa.us, pavan.deolasee@gmail.com, pgsql-hackers@postgresql.org
Subject: Re: [PATCHES] VACUUM Improvements - WIP Patch
In-Reply-To: <87bq10nx2p.fsf@oxford.xeocode.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox