Re: [PATCHES] GIN improvements

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Teodor Sigaev <teodor(at)sigaev(dot)ru>
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 19:01:04
Message-ID: 2818.1216753264@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Teodor Sigaev <teodor(at)sigaev(dot)ru> writes:
> That's close to trivial to revert this piece to add cleanup call to
> ginbulkdelete/ginvacuumcleanup. Early variants used this variant.

Yeah, I think we should do it that way.

On reflection I don't think you even need the amvacuumstartup call,
because it is *not* safe to assume that an index cleanup operation
there will guarantee that vacuum won't try to remove pending tuples.
Remember that a tuple inserted by a transaction that later aborted
is DEAD and can be reclaimed instantly by VACUUM. So while in the
case of VACUUM FULL it might be okay to call index_cleanup only
once, for regular VACUUM I think you really have to call it within
each bulkdelete operation. There's probably no point in optimizing
it away in VACUUM FULL either, since surely it'll be fast to call
index_cleanup when there's nothing in the pending list?

> - 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.

Yeah, I was going to complain about that next :-). Autovacuum isn't
going to trigger as a result of INSERT operations; somehow we have
to teach it what to do for GIN indexes. I remember we discussed this
at PGCon but I don't think we decided exactly what to do...

> Do I revert that piece?

I've already made a number of changes to the patch; let me keep working
on it and send it back to you later.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Francisco Reyes 2008-07-22 19:30:21 Re: [ADMIN] shared_buffers and shmmax
Previous Message Simon Riggs 2008-07-22 18:56:36 Transaction-controlled robustness for replication

Browse pgsql-patches by date

  From Date Subject
Next Message Martin Zaun 2008-07-23 00:19:16 Re: [PATCHES] odd output in restore mode
Previous Message Teodor Sigaev 2008-07-22 18:24:40 Re: [PATCHES] GIN improvements