Skip site navigation (1) Skip section navigation (2)

Re: DELETE with LIMIT (or my first hack)

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>, Daniel Loureiro <loureirorg(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: DELETE with LIMIT (or my first hack)
Date: 2010-11-30 20:52:36
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Josh BerkusDate: 2010-11-30 20:58:09
Subject: Re: Spread checkpoint sync
Previous:From: Tom LaneDate: 2010-11-30 20:49:07
Subject: Re: profiling connection overhead

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group