| From: | Marko Tiikkaja <marko(at)joh(dot)to> |
|---|---|
| To: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Rukh Meski <rukh(dot)meski(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: LIMIT for UPDATE and DELETE |
| Date: | 2014-09-10 09:33:29 |
| Message-ID: | 54101AE9.8070402@joh.to |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 9/10/14 11:25 AM, Etsuro Fujita wrote:
> The reason is because I think that after implementing #2, we should
> re-implement this feature by extending the planner to produce a plan
> tree such as ModifyTable+Limit+Append, maybe with LockRows below the
> Limit node. Such an approach would prevent duplication of the LIMIT
> code in ModifyTable, making the ModifyTable code more simple, I think.
You can already change *this patch* to do ModifyTable <- Limit <-
LockRows. If we think that's what we want, we should rewrite this patch
right now. This isn't a reason not to implement LIMIT without ORDER BY.
Like I said upthread, I think LockRows is a bad idea, but I'll need to
run some performance tests first. But whichever method we decide to
implement for this patch shouldn't need to be touched when the changes
to UPDATE land, so your reasoning is incorrect.
.marko
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2014-09-10 09:55:13 | Re: PENDING_LIST_CLEANUP_SIZE - maximum size of GIN pending list Re: HEAD seems to generate larger WAL regarding GIN index |
| Previous Message | Florian Pflug | 2014-09-10 09:32:22 | Re: [TODO] Process pg_hba.conf keywords as case-insensitive |