[ back to this thread... ] Heikki Linnakangas <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend