From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Heikki <hlinnaka(at)iki(dot)fi> |
Subject: | Re: Feedback on getting rid of VACUUM FULL |
Date: | 2015-04-27 21:21:36 |
Message-ID: | 553EA860.8020108@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 4/25/15 6:30 AM, Simon Riggs wrote:
> On 24 April 2015 at 22:36, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com
> <mailto:Jim(dot)Nasby(at)bluetreble(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2015-04-27 21:52:58 | Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0, parser/executor stuff |
Previous Message | Jim Nasby | 2015-04-27 21:01:13 | Re: Reducing tuple overhead |