Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 80BF164FD9A for ; Thu, 27 Nov 2008 19:16:16 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 18330-06 for ; Thu, 27 Nov 2008 19:16:18 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mail.postgresql.org (Postfix) with ESMTP id D3CB564FCBE for ; Thu, 27 Nov 2008 19:16:13 -0400 (AST) Received: by ug-out-1314.google.com with SMTP id k40so1860146ugc.7 for ; Thu, 27 Nov 2008 15:16:11 -0800 (PST) Received: by 10.210.74.17 with SMTP id w17mr7986408eba.152.1227824103044; Thu, 27 Nov 2008 14:15:03 -0800 (PST) Received: from oxford.xeocode.com.enterprisedb.com ([87.127.95.198]) by mx.google.com with ESMTPS id q9sm282852gve.30.2008.11.27.14.15.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 27 Nov 2008 14:15:02 -0800 (PST) To: Heikki Linnakangas Cc: Teodor Sigaev , Tom Lane , Pgsql Hackers Subject: Re: [PATCHES] GIN improvements In-Reply-To: <492F04D9.5070404@enterprisedb.com> (Heikki Linnakangas's message of "Thu\, 27 Nov 2008 22\:36\:41 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-Draft-From: ("nnimap+imap.gmail.com:HACKERS" 49909) References: <483FD205.4090904@sigaev.ru> <486BC501.6060605@sigaev.ru> <27880.1215810535@sss.pgh.pa.us> <487A6E0C.3090600@sigaev.ru> <8993.1216843701@sss.pgh.pa.us> <4888A594.6010102@sigaev.ru> <490B07BA.6030109@sigaev.ru> <492F04D9.5070404@enterprisedb.com> From: Gregory Stark Organization: EnterpriseDB Date: Thu, 27 Nov 2008 22:14:59 +0000 Message-ID: <87iqq8n7do.fsf@oxford.xeocode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 200811/1837 X-Sequence-Number: 128549 Heikki Linnakangas writes: > I think we need a hard limit on the number of list pages, before we can > consider accepting this patch. After the limit is full, the next inserter can > flush the list, inserting the tuples in the list into the tree, or just fall > back to regular, slow, inserts. I do like the idea of having the work fall to vacuum though. Perhaps we need some way for autovacuum to ask an access method what shape an index is in and whether it needs vacuuming? Or more likely a separate command from vacuum that specifically cleans up an index. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning