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