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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
