From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(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 19:45:39 |
Message-ID: | 1291146339.30414.10.camel@jdavis-ux.asterdata.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Marko Tiikkaja | 2010-11-30 19:47:24 | Re: DELETE with LIMIT (or my first hack) |
Previous Message | Peter Eisentraut | 2010-11-30 19:37:13 | Re: profiling connection overhead |