Re: Improve the concurency of vacuum full table and select statement on the same relation
От | Robert Haas |
---|---|
Тема | Re: Improve the concurency of vacuum full table and select statement on the same relation |
Дата | |
Msg-id | CA+TgmoZ2G2_fUQJYp1F5KBb0bLdvkWjM=6-Bc6n=_MuwbBRO6A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Improve the concurency of vacuum full table and select statement on the same relation (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
Ответы |
Re: Improve the concurency of vacuum full table and select
statement on the same relation
Re: Improve the concurency of vacuum full table and select statement on the same relation |
Список | pgsql-hackers |
On Thu, Oct 15, 2015 at 8:28 PM, Jim Nasby <Jim.Nasby@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
В списке pgsql-hackers по дате отправления: