| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, 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 21:18:15 |
| Message-ID: | 4247.1291151895@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> 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.
That's just a variation of the Sort/Limit/ModifyTable approach. It
doesn't fix the problem of how ModifyTable knows which table each row
came from, and it doesn't fix the problem of the rows not being all the
same rowtype. (In fact it makes the latter worse, since now MergeAppend
has to be included in whatever kluge you invent to work around it.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2010-11-30 22:01:02 | Re: DELETE with LIMIT (or my first hack) |
| Previous Message | Dimitri Fontaine | 2010-11-30 21:10:55 | Re: DELETE with LIMIT (or my first hack) |