Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 054899FB792 for ; Mon, 25 Jun 2007 20:52:29 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024) with ESMTP id 59970-04 for ; Mon, 25 Jun 2007 20:52:21 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 7E6339FA2F4 for ; Mon, 25 Jun 2007 20:52:24 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.1/8.14.1) with ESMTP id l5PNqMDN008245; Mon, 25 Jun 2007 19:52:22 -0400 (EDT) To: Heikki Linnakangas cc: Jaime Casanova , PostgreSQL-patches Subject: Re: Maintaining cluster order on insert In-reply-to: <46761DB7.7070505@enterprisedb.com> References: <200705152223.l4FMNJa17969@momjian.us> <464A33AB.1050401@enterprisedb.com> <20070516003810.GI20707@nasby.net> <464B15EF.4000808@enterprisedb.com> <464D96D6.1030608@enterprisedb.com> <464F410C.8090900@enterprisedb.com> <10328.1182113758@sss.pgh.pa.us> <46761DB7.7070505@enterprisedb.com> Comments: In-reply-to Heikki Linnakangas message dated "Mon, 18 Jun 2007 06:52:55 +0100" Date: Mon, 25 Jun 2007 19:52:22 -0400 Message-ID: <8244.1182815542@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200706/296 X-Sequence-Number: 2912 [ back to this thread... ] Heikki Linnakangas writes: > Tom Lane wrote: >> The other question is why is execMain involved in this? That makes the >> design nonfunctional for tuples inserted in any other way than through >> the main executor --- COPY for instance. Also, if this is successful, >> I could see using it on system catalogs eventually. I'm inclined to >> think that the right design is for heap_insert to call amsuggestblock >> for itself, or maybe even push that down to RelationGetBufferForTuple. > Hmm. My first reaction on that is that having heap_insert reach into an > index is a modularity violation. It wouldn't be too hard to make similar > changes to COPY that I did to the executor. Well, this entire patch is a modularity violation by definition. Bringing the executor into it just makes the damage worse, by involving relatively high-level code in the communication between two relatively low-level bits of code, and ensuring that we'll have to involve still other bits of high-level code in future if we want to make the behavior work in more scenarios. There is a problem with my suggestion of relying on the relcache: that would only give you the index relation's OID, not a handle to an open Relation for it. I'm not sure this is a killer, however, as the cost of an index_open/index_close cycle isn't really much more than a dynahash search if the index is already open and locked by some upper code level. regards, tom lane