Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 89226650497 for ; Tue, 22 Jul 2008 16:53:49 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 01094-04-3 for ; Tue, 22 Jul 2008 16:53:28 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 966DA650865 for ; Tue, 22 Jul 2008 16:01:06 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id m6MJ14Nn002819; Tue, 22 Jul 2008 15:01:04 -0400 (EDT) To: Teodor Sigaev cc: Oleg Bartunov , Pgsql Hackers Subject: Re: [PATCHES] GIN improvements In-reply-to: <488625E8.4070203@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> <1636.1216749010@sss.pgh.pa.us> <488625E8.4070203@sigaev.ru> Comments: In-reply-to Teodor Sigaev message dated "Tue, 22 Jul 2008 22:24:40 +0400" Date: Tue, 22 Jul 2008 15:01:04 -0400 Message-ID: <2818.1216753264@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200807/1006 X-Sequence-Number: 121266 Teodor Sigaev 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