On 10/16/15 10:04 AM, Robert Haas wrote:
On Thu, Oct 15, 2015 at 8:28 PM, Jim Nasby <jim.na...@bluetreble.com> wrote:
It's just how the authors of pg_repack decided to handle it. It seems pretty
reasonable, since you probably don't want an errant DDL statement to cause
the rollback of hours or days of pg_repack work.
Ultimately, I don't think you'll find many people interested in working on
this, because the whole goal is to never need VACUUM FULL or pg_repack. If
you're clustering just for the sake of clustering, that has it's own set of
difficulties that should be addressed.
I think the topic of online table reorganization is a pretty important
one, actually. That is a need that we have had for a long time,
creates serious operational problems for users, and it's also a need
that is not going away. I think the chances of eliminating that need
completely, even if we rearchitected or heap storage, are nil.
Yeah, which is why I made the comment about CLUSTER.
I think the bigger issue is that it's a very hard problem to solve.
ISTM nothing can be done here until there's some way to influence how
pages get pulled from the FSM (IE: pull from one of the first X pages
with free space). Maybe having some way to expose that would be enough
of a start.
pg_repack is one approach, but I've heard more than one person say
that, as C-3PO said about the asteroid, it may not be entirely stable.
I looked at it recently, and it seems to be under active development.
But I agree it'd be better if we could handle this internally.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
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
