Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 67B9E6505C0 for ; Tue, 22 Jul 2008 17:02:39 -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 09200-04-7 for ; Tue, 22 Jul 2008 17:02:20 -0300 (ADT) Received: from mx3.hub.org (mx3.hub.org [206.223.169.73]) by postgresql.org (Postfix) with ESMTP id 23C216509E0 for ; Tue, 22 Jul 2008 16:10:48 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from hook.sigaev.ru (hook.sigaev.ru [212.192.243.50]) by mx3.hub.org (Postfix) with ESMTP id B578D37B7A9 for ; Tue, 22 Jul 2008 15:26:15 -0300 (ADT) Received: by hook.sigaev.ru (Postfix, from userid 1003) id 66DFE39906; Tue, 22 Jul 2008 22:24:48 +0400 (MSD) Received: from xor.sai.msu.ru (xor.sai.msu.ru [212.192.243.97]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hook.sigaev.ru (Postfix) with ESMTP id 93AEB39907; Tue, 22 Jul 2008 22:24:45 +0400 (MSD) Message-ID: <488625E8.4070203@sigaev.ru> Date: Tue, 22 Jul 2008 22:24:40 +0400 From: Teodor Sigaev User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.15) Gecko/20080715 SeaMonkey/1.1.10 MIME-Version: 1.0 To: Tom Lane CC: Oleg Bartunov , Pgsql Hackers Subject: Re: [PATCHES] GIN improvements 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> In-Reply-To: <1636.1216749010@sss.pgh.pa.us> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit 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/1009 X-Sequence-Number: 121269 > 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@sigaev.ru WWW: http://www.sigaev.ru/