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  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Re: Improve the concurency of vacuum full table and select statement on the same relation  (Jinyu <call_jinyu@126.com>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: TODO list updates
Следующее
От: Robert Haas
Дата:
Сообщение: Re: pg_dump LOCK TABLE ONLY question