From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Joshua Tolley <eggyknap(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Feedback on getting rid of VACUUM FULL |
Date: | 2009-09-17 13:45:32 |
Message-ID: | 603c8f070909170645t2023fc6eq5166f58a97a6675b@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Sep 17, 2009 at 9:35 AM, Joshua Tolley <eggyknap(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2009-09-17 14:03:00 | Re: generic copy options |
Previous Message | Kevin Grittner | 2009-09-17 13:38:35 | Re: generic copy options |