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?
In response to
pgsql-hackers by date
|Next:||From: Marko Tiikkaja||Date: 2010-11-30 19:47:24|
|Subject: Re: DELETE with LIMIT (or my first hack)|
|Previous:||From: Peter Eisentraut||Date: 2010-11-30 19:37:13|
|Subject: Re: profiling connection overhead|