Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 7995C650317 for ; Thu, 24 Jul 2008 17:30:24 -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 62163-05 for ; Thu, 24 Jul 2008 17:30:11 -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 4ACF765030C for ; Thu, 24 Jul 2008 17:30:12 -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 m6OKU9dk010900; Thu, 24 Jul 2008 16:30:09 -0400 (EDT) To: Teodor Sigaev cc: Pgsql Hackers Subject: Re: [PATCHES] GIN improvements In-reply-to: <4888D6DB.8030100@sigaev.ru> 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> <7913.1216918895@sss.pgh.pa.us> <4888D6DB.8030100@sigaev.ru> Comments: In-reply-to Teodor Sigaev message dated "Thu, 24 Jul 2008 23:24:11 +0400" Date: Thu, 24 Jul 2008 16:30:09 -0400 Message-ID: <10899.1216931409@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/1149 X-Sequence-Number: 121409 Teodor Sigaev writes: > - GiST already supports both scan directions in theory, but page split may > change order between forward and backward scans (user-defined pageSplit doesn't > preserve order of tuples). Holding of split until end of scan will produce > unacceptable concurrency level. > - GIN doesn't support backward scan direction and will not support in close > future. Okay. I'll see about fixing the planner to not assume that GIST or GIN indexscans are scrollable. The cleanest way to do this is to introduce a new bool column in pg_am rather than hard-wiring assumptions about which AMs can do it. However (a) that's not back-patchable and (b) it'll create a merge conflict with your patch, if you're still going to add a new AM function column. I think that aminsertcleanup per se isn't needed, but if we want an "amanalyze" there'd still be a conflict. Where are we on that? regards, tom lane