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.1253147...@sss.pgh.pa.us
[2] http://postgresql.org/message-id/3631.1253149...@sss.pgh.pa.us
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
