At Thu, 17 Jun 2021 12:56:42 -0400, Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote in > On 2021-Jun-17, Kyotaro Horiguchi wrote: > > > I don't see a call to hash_*seq*_search there. Instead, I see one in > > ReorderBufferCheckMemoryLimit(). > > Doh, of course -- I misread. > > ReorderBufferCheckMemoryLimit is new in pg13 (cec2edfa7859) so now at > least we have a reason why this workload regresses in pg13 compared to > earlier releases. > > Looking at the code, it does seem that increasing the memory limit as > Amit suggests might solve the issue. Is that a practical workaround?
I believe so generally. I'm not sure about the op, though. Just increasing the working memory to certain size would solve the problem. There might be a potential issue that it might be hard like this case for users to find out that the GUC works for their issue (if actually works). pg_stat_replicatoin_slots.spill_count / spill_txns could be a guide for setting logical_decoding_work_mem. Is it worth having additional explanation like that for the GUC variable in the documentation? regards. -- Kyotaro Horiguchi NTT Open Source Software Center
