Re: LIMIT for UPDATE and DELETE

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

In response to

Responses

Browse pgsql-hackers by date

  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.