Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions
От | Tomas Vondra |
---|---|
Тема | Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions |
Дата | |
Msg-id | 20190927112520.3kco6tqbhcvlk6cd@development обсуждение исходный текст |
Ответ на | Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions
|
Список | pgsql-hackers |
On Fri, Sep 27, 2019 at 02:33:32PM +0530, Amit Kapila wrote: >On Tue, Jan 9, 2018 at 7:55 AM Peter Eisentraut ><peter.eisentraut@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? > IMHO it's similar to autovacuum_work_mem - we have an independent setting, but most people use it as -1 so we use maintenance_work_mem as a default value. I think it makes sense to do the same thing here. It does ad an extra knob anyway (I don't think we should just use maintenance_work_mem directly, the user should have an option to override it when needed). But most users will not notice. FWIW I don't think we should use work_mem, maintenace_work_mem seems somewhat more appropriate here (not related to queries, etc.). >If we can't use work_mem, then I think the name proposed by you >(logical_decoding_work_mem) sounds good to me. > Yes, that name seems better. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: