On Tue, Nov 30, 2010 at 2:45 PM, Jeff Davis <pg...@j-davis.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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers