From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | 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 01:48:20 |
Message-ID: | 4523.1253152100@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Sep 16, 2009 at 9:35 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
>>> * Shrink a table concurrently - when no dedicated time available
>>
>> Wishful thinking, which should not stop us from proceeding with the
>> solutions we know how to implement.
> The UPDATE-style tuple-mover might work for this too, for certain
> workloads. If most of your transactions are short, and the server
> load is not too high, it might be OK to lock the table, move a few
> tuples, lock the table, move a few tuples, etc. Now if you have
> long-running transactions, not so much.
Yeah, I was just wondering about that myself. 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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2009-09-17 03:07:28 | Re: Feedback on getting rid of VACUUM FULL |
Previous Message | Robert Haas | 2009-09-17 01:41:13 | Re: Feedback on getting rid of VACUUM FULL |