[ 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

Reply via email to