Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eWp73-0006Pa-Tc for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Jan 2018 19:54:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eWp73-000166-5Y for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Jan 2018 19:54:09 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eWp72-00015w-VF for pgsql-hackers@lists.postgresql.org; Wed, 03 Jan 2018 19:54:09 +0000 Received: from mail-wm0-x232.google.com ([2a00:1450:400c:c09::232]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eWp6z-0006NG-GI for pgsql-hackers@postgresql.org; Wed, 03 Jan 2018 19:54:08 +0000 Received: by mail-wm0-x232.google.com with SMTP id r78so4615232wme.5 for ; Wed, 03 Jan 2018 11:54:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=pBapTjZPSABk/XF7gUhJ0qCkh1fahCfUiHYzHbg80KA=; b=FPVPNI/qtnkmTkz8dLQJdnXlsnm803sIcyebWg6eQDi63x5b72XoV9j3GvAUotaNDD oEQVvEijKA+3RPgg5GinaiUj/vIWhuu5qcHJjAdRm7cCdOQLag7pKgZLwmFoUU5Gidu5 u2R0VM3wWIYzDQrVPHUNb8MC5TOLsD9cGQDgcd8a3cYBXU6nY4OuJqYWDh6qF6mjc16P r2fiEnr10MgzbftQCyXVAONJeXPWtV1MQOnNcWUngy8DWeXMGMy5jkNNROANpNb7tvXD kAEkHIXeQ5ggnIi9op3hdEBCLbUePuSH6oJTU5K1B3OshETSH/JzYHudbafDD8p7TDau WEkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=pBapTjZPSABk/XF7gUhJ0qCkh1fahCfUiHYzHbg80KA=; b=aQ0EukUlEYxARP9CmzKPi4Fh6efk+ql01eNBSKikyKMyOoqg+gI9hZqEYLPFeP/jFv QYul57onW48P8afh9vU0337e9uh3ojd+VArGijlN3iqZOgGFtxobPkA4DCqDBnOcgq3z x0Ic3txTuQRcdphnkU4+2W6un/hb/4FyxkeCH2vlJ7wxs5nuxeYy2feqwC619b85yneR V+cZ4d9pZdxunk60P3s1GC196rSYOgh167KzAqeb1EKdYh1DPtLhZNhgZaOOLI0oBTpk 4lC4nO+dPG3OQUnNeimiB7hsKAY7k2HqqrFy8NFLFOCScL10qUFvsY61uIG07XT/JsYH YfPA== X-Gm-Message-State: AKGB3mJrpp2FeltG1C1JJecP8tTREtaYef3tPe8le7Z8Nb0rL1lMTi0n 9wc4mFWWz1bNEU9COd/3I/t9k1kg2Wq8NFr92uzXUWQlynOyTgUBady3pmcYIqEkVP4/WFen8yX 8oCKAZZ8mSnw642E0L7WlTa0O0ePjT4g8VNoxF+j/6/n1pfyHnYrBni2VqdGsanohEasHMKrsbR r7ASscuA3F X-Google-Smtp-Source: ACJfBotUfL1J0zD5HIZezKUtdyPmsh+/wgPZG9zybsiMO2z2svQoVmsjgkK0kc7Kl9Uan+RZDhZlgQ== X-Received: by 10.28.66.145 with SMTP id k17mr2051445wmi.32.1515009243326; Wed, 03 Jan 2018 11:54:03 -0800 (PST) Received: from [10.137.2.19] (ip-78-102-97-226.net.upcbroadband.cz. [78.102.97.226]) by smtp.gmail.com with ESMTPSA id 31sm1905770wrw.8.2018.01.03.11.54.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jan 2018 11:54:02 -0800 (PST) Subject: Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions To: Peter Eisentraut , PostgreSQL Hackers References: <688b0b7f-2f6c-d827-c27b-216a8e3ea700@2ndquadrant.com> <3530384f-f73a-186a-a728-8eeeb5533a10@2ndquadrant.com> From: Tomas Vondra Message-ID: <262cc9df-0d19-3fca-f899-0890bd2cd4be@2ndquadrant.com> Date: Wed, 3 Jan 2018 20:53:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <3530384f-f73a-186a-a728-8eeeb5533a10@2ndquadrant.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk 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