Re: Improving replay of XLOG_BTREE_VACUUM records

> 7 янв. 2016 г., в 5:26, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> написал(а):
>
> On Thu, Jan 7, 2016 at 12:20 AM, Alvaro Herrera
> <alvherre(at)2ndquadrant(dot)com <mailto:alvherre(at)2ndquadrant(dot)com>> wrote:
>> Vladimir Borodin wrote:
>>
>>> There are situations in which vacuuming big btree index causes stuck
>>> in WAL replaying on hot standby servers for quite a long time. I’ve
>>> described the problem in more details in this thread [0]. Below in
>>> that thread Kevin Grittner proposed a good way for improving btree
>>> scans so that btree vacuuming logic could be seriously simplified.
>>> Since I don’t know when that may happen I’ve done a patch that makes
>>> some improvement right now. If Kevin or someone else would expand [1]
>>> for handling all types of btree scans, I suppose, my patch could be
>>> thrown away and vacuuming logic should be strongly rewritten.
>>
>> You submitted this patch in May 2015 -- and 7 months later, Simon came
>> up with another patch that's supposed to fix the underlying problem, so
>> that this shouldn't be a problem anymore.
>>
>> 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.

>
> Simon's patch (justly) does not update lastBlockVacuumed in the case
> of toast indexes, but Vladimir's patch would still optimize this case,
> no?

I suppose, in case of _not_ toast indexes. But yes, seems that my patch should help in that case too.

> --
> Michael

--
May the force be with you…
https://simply.name