On Thu, Jan 7, 2016 at 12:20 AM, Alvaro Herrera <alvhe...@2ndquadrant.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.
Simon's patch (justly) does not update lastBlockVacuumed in the case of toast indexes, but Vladimir's patch would still optimize this case, no? -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
