Re: Feedback on getting rid of VACUUM FULL

On 4/24/15 3:34 PM, Alvaro Herrera wrote:
> Jim Nasby wrote:
>
>> Honestly, I'd prefer we exposed some way to influence where a new tuple gets
>> put, and perhaps better ways of accessing tuples on a specific page. That
>> would make it a lot easier to handle this in userspace, but it would also
>> make it easier to do things like concurrent clustering. Or just organizing a
>> table however you wanted.
>
> That's great and all, but it doesn't help people who have already, for
> whatever reason, ran into severe bloat and cannot take long enough
> downtime to run VACUUM FULL.
>
>> That said, why not just pull what Heikki did into contrib, and add the
>> necessary mode to heap_update?
>
> Sure, that's what I suggest.  We just need to fix the bugs and (as Tom
> puts it) "infelicities."

It looks like the biggest complaint (aside from allowing a limited 
number of tuples to be moved) is in [1] and [2], where Tom is saying 
that you can't simply call heap_update() like this without holding an 
exclusive lock on the table. Is that because we're not actually changing 
the tuple?

Another issue is both HOT and KeyUpdate; I think we need to completely 
ignore/over-ride that stuff for this.

Instead of adding forcefsm, I think it would be more useful to accept a 
target block number. That way we can actually control where the new 
tuple goes. For this particular case we'd presumably go with normal FSM 
page selection logic, but someone could chose to to do something more 
sophisticated if they wanted.

[1] http://postgresql.org/message-id/3409.1253147817@sss.pgh.pa.us
[2] http://postgresql.org/message-id/3631.1253149221@sss.pgh.pa.us
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com