Teodor Sigaev <[EMAIL PROTECTED]> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
