Re: [PATCHES] GIN improvements

From: Teodor Sigaev <teodor(at)sigaev(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCHES] GIN improvements
Date: 2008-07-22 18:24:40
Message-ID: 488625E8.4070203@sigaev.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

> 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.
Actually, lock doesn't needed. Just bulkdelete should not try to remove not yet
"insertcleanuped" items pointer. That's easy because VacPageList is prepared
before insertcleanup call.

> Maybe it'd be better if ambulkdelete *did* scan the pending list?

I don't like that idea because it requires to add a lot of code (concurrent
deletion of pages in list), much simpler to call insertcleanup inside
ginbulkdelete/ginvacuumcleanup.

> You'd still need at least page-level locking but perhaps not anything
> stronger.

That's close to trivial to revert this piece to add cleanup call to
ginbulkdelete/ginvacuumcleanup. Early variants used this variant.
Reasons for new variant was:
- defining needing of call of insertcleanup, and stats argument was used for
it in both function. If it's a NULL then call cleanup.
- I thought about statistic-based trigger for separate call of insertcleanup.
Trigger should be fired on massive insert/update events very similar to
trigger on massive delete for ambulkdelete. I'm very sorry but I didn't do it
yet, and definitely I need some help here.

Do I revert that piece?

--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Shane Ambler 2008-07-22 18:34:33 Re: Do we really want to migrate plproxy and citext into PG core distribution?
Previous Message Simon Riggs 2008-07-22 18:23:05 Re: Plans for 8.4

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2008-07-22 19:01:04 Re: [PATCHES] GIN improvements
Previous Message Tom Lane 2008-07-22 17:50:10 Re: [PATCHES] GIN improvements