Re: Improving replay of XLOG_BTREE_VACUUM records
От | Alvaro Herrera |
---|---|
Тема | Re: Improving replay of XLOG_BTREE_VACUUM records |
Дата | |
Msg-id | 20160108133642.GA566048@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: Improving replay of XLOG_BTREE_VACUUM records (Vladimir Borodin <root@simply.name>) |
Ответы |
Re: Improving replay of XLOG_BTREE_VACUUM records
|
Список | pgsql-hackers |
Vladimir Borodin wrote: > > > 7 янв. 2016 г., в 5:26, Michael Paquier <michael.paquier@gmail.com> написал(а): > > > > On Thu, Jan 7, 2016 at 12:20 AM, Alvaro Herrera > > <alvherre@2ndquadrant.com <mailto:alvherre@2ndquadrant.com>> wrote: > >> Would you please have a look at Simon's patch, in particular verify > >> whether it solves the performance dip in your testing environment? > >> https://www.postgresql.org/message-id/CANP8%2BjJuyExr1HnTAdZraWsWkfc-octhug7YPtzPtJcYbyi4pA%40mail.gmail.com > >> (Note there's an updated patch a few emails down the thread.) > >> > >> If it seems to fix the problem for you, I think we should mark yours > >> rejected and just apply Simon’s. > > Ok, I’ll try this patch with my use case. Basically, it’s not so easy > now since I’ve partitioned that big table to not have such problems > but there is a way to reproduce it once again. If it helps, I agree > that my should be rejected in favor of the Simon’s patch because my > patch just reduces replication lag but Simon’s seems to remove lag at > all. I would agree except for the observation on toast indexes. I think that's an important enough use case that perhaps we should have both. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: