On Tue, Jan 9, 2018 at 7:55 AM Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > > On 1/3/18 14:53, Tomas Vondra wrote: > >> I don't see the need to tie this setting to maintenance_work_mem. > >> maintenance_work_mem is often set to very large values, which could > >> then have undesirable side effects on this use. > > > > Well, we need to pick some default value, and we can either use a fixed > > value (not sure what would be a good default) or tie it to an existing > > GUC. We only really have work_mem and maintenance_work_mem, and the > > walsender process will never use more than one such buffer. Which seems > > to be closer to maintenance_work_mem. > > > > Pretty much any default value can have undesirable side effects. > > Let's just make it an independent setting unless we know any better. We > don't have a lot of settings that depend on other settings, and the ones > we do have a very specific relationship. > > >> Moreover, the name logical_work_mem makes it sound like it's a logical > >> version of work_mem. Maybe we could think of another name. > > > > I won't object to a better name, of course. Any proposals? > > logical_decoding_[work_]mem? >
Having a separate variable for this can give more flexibility, but OTOH it will add one more knob which user might not have a good idea to set. What are the problems we see if directly use work_mem for this case? If we can't use work_mem, then I think the name proposed by you (logical_decoding_work_mem) sounds good to me. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
