From: Tom Lane <tgl@sss.pgh.pa.us>
To: Heikki Linnakangas <heikki@enterprisedb.com>
Cc: Jaime Casanova <systemguards@gmail.com>
Cc: PostgreSQL-patches <pgsql-patches@postgresql.org>
Subject: Re: Maintaining cluster order on insert
Date: Mon, 25 Jun 2007 19:52:22 -0400
Message-ID: <8244.1182815542@sss.pgh.pa.us> (raw)
In-Reply-To: <46761DB7.7070505@enterprisedb.com>
References: <200705152223.l4FMNJa17969@momjian.us>
<464A33AB.1050401@enterprisedb.com>
<20070516003810.GI20707@nasby.net>
<464B15EF.4000808@enterprisedb.com>
<c2d9e70e0705172153g3207adb6kd4abdfdf3a9215ff@mail.gmail.com>
<464D96D6.1030608@enterprisedb.com>
<c2d9e70e0705182205o44a4bbbft18a73b9de91de726@mail.gmail.com>
<464F410C.8090900@enterprisedb.com>
<10328.1182113758@sss.pgh.pa.us>
<46761DB7.7070505@enterprisedb.com>
[ back to this thread... ]
Heikki Linnakangas <heikki@enterprisedb.com> 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, heikki@enterprisedb.com, systemguards@gmail.com, pgsql-patches@postgresql.org
Subject: Re: Maintaining cluster order on insert
In-Reply-To: <8244.1182815542@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox