Re: Feedback on getting rid of VACUUM FULL

On 4/25/15 6:30 AM, Simon Riggs wrote:
> On 24 April 2015 at 22:36, Jim Nasby <Jim.Nasby@bluetreble.com
> <mailto:Jim.Nasby@bluetreble.com>> wrote:
>
>     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
>
>
> I don't think specifying exact blocks will help, it will get us in more
> trouble in the long run.
>
> I think we need to be able to specify these update placement strategies
...
> and these new block selection strategies
...
> We can also design a utility to actively use TARGBLOCK_NEW and
> FSM_SHRINK to reduce table size without blocking writes.

I generally agree, but was trying to keep the scope on this more 
manageable. A first step in this direction is just providing a method to 
move a specific tuple to a specific page; if there's no room there throw 
an error. Having some kind of SQL level support for that will be a lot 
easier than adding those other modes to the FSM, and will at least allow 
users to deal with bloat themselves.

> But this is all stuff for 9.6...

Definitely. :)
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com