On Tue, Nov 30, 2010 at 2:45 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> On Tue, 2010-11-30 at 11:12 -0500, Robert Haas wrote:
>> > 3. This doesn't work tremendously well for inheritance trees, where
>> > ModifyTable acts as sort of an implicit Append node. You can't just
>> > funnel all the tuples through one Sort or Limit node because they aren't
>> > all the same rowtype. (Limit might perhaps not care, but Sort will.)
>> > But you can't have a separate Sort/Limit for each table either, because
>> > that would give the wrong behavior. Another problem with funneling all
>> > the rows through one Sort/Limit is that ModifyTable did need to know
>> > which table each row came from, so it can apply the modify to the right
>> > table.
>> Could you possibly have ModifyTable -> Limit -> MergeAppend?
> Before MergeAppend knows which tuple to produce, it needs to see the
> tuples (at least the first one from each of its children), meaning that
> it needs to pull them through ModifyTable; and at that point it's
> already too late.
> Also, assuming LIMIT K, MergeAppend will have N children, meaning N
> limits, meaning an effective limit of K*N rather than K.
> Can you be a little more specific about what you mean?
You seem to be imagining the MergeAppend node on top, but I had it in
the other order in my mind. The ModifyTable node would be the
outermost plan node, pulling from the Limit, which would deliver the
first n table rows from the MergeAppend, which would be reponsible for
getting it from the various child tables.
The Enterprise PostgreSQL Company
In response to
pgsql-hackers by date
|Next:||From: Josh Berkus||Date: 2010-11-30 20:58:09|
|Subject: Re: Spread checkpoint sync|
|Previous:||From: Tom Lane||Date: 2010-11-30 20:49:07|
|Subject: Re: profiling connection overhead |