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. I think the bigger issue is that it's a very hard problem to solve. 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
