From: | Marko Tiikkaja <marko(at)joh(dot)to> |
---|---|
To: | 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>, Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, 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-09 10:37:23 |
Message-ID: | 540ED863.6020402@joh.to |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 9/9/14 11:57 AM, Heikki Linnakangas wrote:
> What's not clear to me is whether it make sense to do 1) without 2) ? Is
> UPDATE .. LIMIT without support for an ORDER BY useful enough?
I'd say so; I could use it right now. I have to remove millions of
lines from a table, but I don't want the live transaction processing to
take a hit, so I have to do it in batches. Granted, some kind of rate
limiting would achieve the same thing for DELETE, but with UPDATE you
also have to consider row locking, and rate limiting wouldn't help with
that at all; it would, in fact, just make it worse. I'll also be
running a big UPDATE like that later today, so that's two uses today
alone for me. And no, these are not routine things so keep your "use
partitions" suggestions to yourselves.
> And if we
> apply this patch now, how much of it needs to be rewritten after 2) ? If
> the answers are "yes" and "not much", then we should review this patch
> now, and put 2) on the TODO list. Otherwise 2) should do done first.
I'd say "not much, if anything at all".
.marko
From | Date | Subject | |
---|---|---|---|
Next Message | Marko Tiikkaja | 2014-09-09 10:46:49 | Re: LIMIT for UPDATE and DELETE |
Previous Message | Kyotaro HORIGUCHI | 2014-09-09 10:31:04 | Re: Escaping from blocked send() reprised. |