Re: DELETE with LIMIT (or my first hack)

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company