On Thu, Sep 17, 2009 at 9:35 AM, Joshua Tolley <eggyk...@gmail.com> wrote: > On Wed, Sep 16, 2009 at 09:48:20PM -0400, Tom Lane wrote: >> Seems like there would >> be lots of situations where short exclusive-lock intervals could be >> tolerated, even though not long ones. So that's another argument >> for being able to set an upper bound on how many tuples get moved >> per call. > > Presumably this couldn't easily be an upper bound on the time spent moving > tuples, rather than an upper bound on the number of tuples moved?
It's probably not worth it. There shouldn't be a tremendous amount of variability in how long it takes to move N tuples, so it's just a matter of finding the right value of N for your system and workload. Making the code more complicated so that it's easier to tune something that isn't very hard to tune anyway doesn't seem like a good trade-off. (Plus, of course, you can't stop in the middle: so you'd end up moving a few tuples and then trying to estimate whether you had enough time left to move a few more... and maybe being wrong... blech.) ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers