On 01/02/2018 04:07 PM, Peter Eisentraut wrote: > On 12/22/17 23:57, Tomas Vondra wrote: >> PART 1: adding logical_work_mem memory limit (0001) >> --------------------------------------------------- > > The documentation in this patch contains some references to later > features (streaming). Perhaps that could be separated so that the > patches can be applied independently. >
Yeah, that's probably a good idea. But now that you mention it, I wonder if "streaming" is really a good term. We already use it for "streaming replication" and it may be quite confusing to use it for another feature (particularly when it's streaming within logical streaming replication). But I can't really think of a better name ... > 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. > 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? > I think we need a way to report on how much memory is actually used, > so the setting can be tuned. Something analogous to log_temp_files > perhaps. > Yes, I agree. I'm just about to submit an updated version of the patch series, that also introduces a few columns pg_stat_replication, tracking this type of stats (amount of data spilled to disk or streamed, etc.). regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services