Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ltBiR-00063k-VV for pgsql-hackers@arkaria.postgresql.org; Tue, 15 Jun 2021 16:15:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ltBiQ-0006XR-UU for pgsql-hackers@arkaria.postgresql.org; Tue, 15 Jun 2021 16:15:02 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ltBiQ-0006XH-K9 for pgsql-hackers@lists.postgresql.org; Tue, 15 Jun 2021 16:15:02 +0000 Received: from mail-io1-xd29.google.com ([2607:f8b0:4864:20::d29]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ltBiO-0004QX-1Z for pgsql-hackers@postgresql.org; Tue, 15 Jun 2021 16:15:02 +0000 Received: by mail-io1-xd29.google.com with SMTP id s26so14892901ioe.9 for ; Tue, 15 Jun 2021 09:14:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=OModbOAXi4wqUffyjXWJBiwrXDY22VLqLCVpm3iwZro=; b=EjvtPjIFTbeSMDET5PvYIDcefmEJ2vIOCRWNJfO7togpkFaQGUSTacLaui0ksGIZIQ ekzx9pmXo+sW+hAKWHIb3QAP7ygQHpbiFWKhcxcRx8BfUH80G3cwj8Co2DuN2rxo5+E8 DuOiQb4zbiUiVfUhB5O7fjO7r/VF3LYa0xUn2TsQKZyEGHsI7KUMS/wNYmBO0mD8zqz2 /ppzgXObYLv24R34SQxZkliDtOFns8n9Fxii7355BujIsloOKukHZc0bCMNfKkniQNU9 L0J8lDyr8ytOc/NJT98SWC5VCc57EkJQAFu+L1dMoSDkUDzccyF7XSClS6XCJpPdflDF +esg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=OModbOAXi4wqUffyjXWJBiwrXDY22VLqLCVpm3iwZro=; b=f1w1TNFS8BYolUmI4Vp7rGsF62berEKQdASP3Ii19+GetMt/VmtOpdFYSC8hQk8HE1 7qGr64AdRcy/T5tyr7DLW8diJzNeazg/TffRDf42bDiLmpnkH48EZl7WleBkkxG2IXV+ hmxSk3kxf1LpO+CCiFd4SuL7lA0Vg256T0moA0SLyARwS0X8vLU9TSWYT9S+uBLZMfp0 4Y/VNC8gRFvWuhqMNu+6KaQby+yKoHCNdKG1mLUb8A5Yc/Of+LYWWyjM3FafAvxw4WYw lbN5av878KJjc+Nfr/IHzQwtLIVvS3txoMBfGZQHAQnVfWBvOgHvQKHwHlFuNTxsqEcG JVBA== X-Gm-Message-State: AOAM531pJ/NcHz1cGh98P3qG4SoIA7NogyFWQY3syLmJin1GVue9HGTP f0e5GjPkhrGdqUWOVCGJ05aW4A== X-Google-Smtp-Source: ABdhPJwh5r1aNJYHE0Stq0r1fo2iGztJEQrmBrWgSWWXwqJ854AN7dklfAJdABWuKuMDUR46NKIbkQ== X-Received: by 2002:a05:6638:1602:: with SMTP id x2mr79963jas.130.1623773698177; Tue, 15 Jun 2021 09:14:58 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id g3sm1668916ilr.59.2021.06.15.09.14.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Jun 2021 09:14:57 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 99E4B800BCE; Tue, 15 Jun 2021 11:14:56 -0500 (CDT) Date: Tue, 15 Jun 2021 11:14:56 -0500 From: Justin Pryzby To: Peter Eisentraut Cc: Michael Paquier , Heikki Linnakangas , Andrey Borodin , pgsql-hackers@postgresql.org, Thomas Munro , Peter Geoghegan , Andres Freund Subject: Re: Different compression methods for FPI Message-ID: <20210615161456.GP31772@telsasoft.com> References: <3252174C-C21D-4711-A038-5230DE465BAE@yandex-team.ru> <20210614012412.GA31772@telsasoft.com> <20210615014208.GK31772@telsasoft.com> <20210615034206.GL31772@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Jun 15, 2021 at 07:53:26AM +0200, Peter Eisentraut wrote: > On 15.06.21 07:37, Michael Paquier wrote: > > > > Actually, I was just thinking that default yes/no/on/off stuff maybe should be > > > > defined to mean "lz4" rather than meaning pglz for "backwards compatibility". > > > +1 > > I am not sure that we have any reasons to be that aggressive about > > this one either, and this would mean that wal_compression=on implies a > > different method depending on the build options. I would just stick > > with the past, careful practice that we have to use a default > > backward-compatible value as default, while being able to use a new > > option. You're right, I hadn't though this through all the way. There's precedent if the default is non-static (wal_sync_method). But I think yes/on/true/1 should be a compatibility alias for a static thing, and then the only option is pglz. Of course, changing the default to LZ4 is still a possibility. > If we think this new thing is strictly better than the old thing, then why > not make it the default. What would be the gain from sticking to the old > default? > > The point that the default would depend on build options is a valid one. > I'm not sure whether it's important enough by itself.