Re: Improving replay of XLOG_BTREE_VACUUM records - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Improving replay of XLOG_BTREE_VACUUM records
Date
Msg-id 20160106152000.GA361349@alvherre.pgsql
Whole thread Raw
In response to Improving replay of XLOG_BTREE_VACUUM records  (Vladimir Borodin <root@simply.name>)
Responses Re: Improving replay of XLOG_BTREE_VACUUM records  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
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.

Thanks!

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Comment typo in namespace.c
Next
From: Dean Rasheed
Date:
Subject: Re: Add numeric_trim(numeric)