From: Tom Lane <tgl@sss.pgh.pa.us>
To: Teodor Sigaev <teodor@sigaev.ru>
Cc: Oleg Bartunov <oleg@sai.msu.su>
Cc: Pgsql Hackers <pgsql-hackers@postgresql.org>
Subject: Re: [PATCHES] GIN improvements
Date: Tue, 22 Jul 2008 13:50:10 -0400
Message-ID: <1636.1216749010@sss.pgh.pa.us> (raw)
In-Reply-To: <48861758.4070507@sigaev.ru>
References: <483FD205.4090904@sigaev.ru>
<486BC501.6060605@sigaev.ru>
<27880.1215810535@sss.pgh.pa.us>
<487A6E0C.3090600@sigaev.ru>
<29437.1216742605@sss.pgh.pa.us>
<48861758.4070507@sigaev.ru>
Teodor Sigaev <teodor@sigaev.ru> writes:
>> I started to look at this. I don't understand why VACUUM does an insert
>> cleanup before starting to vacuum, but VACUUM FULL doesn't?
> Hmm. May be I missed something, but I don't understand where and what... I tried
> to track all places of ambultdelete call. aminsertcleanup should be called
> before any ambulkdelete, because ambulkdelete doesn't scan pending list which
> can store items to be deleted and hence index will store item pointers to absent
> tuples.
>> needed is the one at vacuum startup, which tempts me to propose that
>> the new AM entry point should be called "amvacuumstartup", instead of
>> wiring in the assumption that what it's for is specifically cleanup
>> of insertions.
> That's possible but inserts into index should be forbidden between
> amvacuumstartup and last call of ambulkdelete.
Well, if that is required to be true then this whole design is pretty
broken, because VACUUM doesn't hold any lock that would guarantee that
no insert happens between the two calls. If we fold the two AM calls
into one call then it'd be okay for the index AM to take such a lock
transiently during the single index-cleanup-plus-bulkdelete call.
For VACUUM FULL there's no such issue because the whole table is locked,
but I still don't see any real point in having two successive index AM
calls when the AM could perfectly well do all the work in one call.
Maybe it'd be better if ambulkdelete *did* scan the pending list?
You'd still need at least page-level locking but perhaps not anything
stronger.
regards, tom lane
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: tgl@sss.pgh.pa.us, teodor@sigaev.ru, oleg@sai.msu.su, pgsql-hackers@postgresql.org
Subject: Re: [PATCHES] GIN improvements
In-Reply-To: <1636.1216749010@sss.pgh.pa.us>
* 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