Re: Improve the concurency of vacuum full table and select statement on the same relation
От | Jim Nasby |
---|---|
Тема | Re: Improve the concurency of vacuum full table and select statement on the same relation |
Дата | |
Msg-id | 56204499.8050501@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: Improve the concurency of vacuum full table and select statement on the same relation (Jinyu <call_jinyu@126.com>) |
Ответы |
Re: Improve the concurency of vacuum full table and select
statement on the same relation
|
Список | pgsql-hackers |
On 10/13/15 10:18 AM, Jinyu wrote: > At 2015-10-12 23:46:12, "Jim Nasby" <Jim.Nasby@BlueTreble.com> wrote: >>On 10/11/15 6:55 AM, Jinyu wrote: >>> Are there other solutions to improve the concurency of vacuum >>> full/cluster and select statement on the same relation? >> >>ISTM that if we were going to put effort into this it makes more sense >>to pull pg_repack into core. BTW, it's approach to this is to summarily >>kill anything that attempts DDL on a table being repacked. Please don't top-post, it leads to confusion. > >>it's approach to this is to summarily kill anything that attempts DDL> on a table being repacked.> Why? I am confusedwith it. Could you please explain this? 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. -- 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
В списке pgsql-hackers по дате отправления: