Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iYYNV-0001WX-LK for pgsql-hackers@arkaria.postgresql.org; Sat, 23 Nov 2019 16:35:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iYYNU-0006yN-FO for pgsql-hackers@arkaria.postgresql.org; Sat, 23 Nov 2019 16:35:20 +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_SHA1:256) (Exim 4.89) (envelope-from ) id 1iYYNT-0006wo-TY for pgsql-hackers@lists.postgresql.org; Sat, 23 Nov 2019 16:35:20 +0000 Received: from mail-pg1-x542.google.com ([2607:f8b0:4864:20::542]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iYYNS-0003JT-20 for pgsql-hackers@postgresql.org; Sat, 23 Nov 2019 16:35:19 +0000 Received: by mail-pg1-x542.google.com with SMTP id k1so4952713pgg.12 for ; Sat, 23 Nov 2019 08:35:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=0YMwuLydMzd6JPb3TGkvRX6Vxnb9h66LcxFiyaKOo/U=; b=CJvTNd4Pu2OYbqzQHtl0cLgYMo2pJJMcgcLdhy5+xOpuhddmyc0Ui8+D6jbOdatwaL yNhnWSQNXBpzSr6hNeV4Y5AUBOsQ8RT8wezoq3pXF+7koYlK0d55t7WEIyChueNuQD/t u5TOFUVLhf8tahmgxQ2AIUdZHvZ611p3SWpHY= 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=0YMwuLydMzd6JPb3TGkvRX6Vxnb9h66LcxFiyaKOo/U=; b=nGGm1KVNbXg4H9D2/nqX60IXh0tXcNUb5o95XxyEEMLcP/pHFpkFIrfiRAhWU1UDaG aM3BjuP0pPrRasbdWb9MHTqEYasiWnI5Hv1o2WzB3oUlBq1M6Ip+n7N4FFnE1e6Vx4mm +6fC5WbtHltEeFK4v8EWZyDbrgmIsFeEklc7PE7wIErHNButbN4nus27rQIeVFVTVRku Oy/hA77lmvvRX5I2yVrwr7TUgb7f3a4L0k0dJRB2oMMxM0WWvJlOaUoqEbX8576asRpE pctvGjWRw7aHUA4nkme0C+m80Mc6gbBQ9/owUQm0GRWDCxnG6qKFIFfxbug+uulGxPKD hAZw== X-Gm-Message-State: APjAAAXVdDDoFewRfVUp3/62M39N5UgsOpg/B+nEhD+HMgrF7zgGOVam oRxzNVcmjV9qc2Apu1lLmcPKiQ== X-Google-Smtp-Source: APXvYqxLLzyi6dPDYMecNKoQoz16lpo1lGhZsOtiEgpeYZU30v2Ds8JuiyRfkMc0ktSyIC9sbZAOFQ== X-Received: by 2002:a62:ce4b:: with SMTP id y72mr9209040pfg.9.1574526915235; Sat, 23 Nov 2019 08:35:15 -0800 (PST) Received: from gust.leadboat.com (ip-184-250-39-184.sanjca.spcsdns.net. [184.250.39.184]) by smtp.gmail.com with ESMTPSA id q34sm2681045pjb.15.2019.11.23.08.35.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Nov 2019 08:35:14 -0800 (PST) Date: Sat, 23 Nov 2019 11:35:09 -0500 From: Noah Misch To: Peter Eisentraut Cc: Robert Haas , Kyotaro Horiguchi , PostgreSQL-development , Dmitry Dolgov <9erthalion6@gmail.com>, Andrew Dunstan , hlinnaka , Michael Paquier Subject: Re: [HACKERS] WAL logging problem in 9.4.3? Message-ID: <20191123163509.GA39577@gust.leadboat.com> References: <20190828.154210.204505676.horikyota.ntt@gmail.com> <20191025.131251.322449872063947371.horikyota.ntt@gmail.com> <1f9a76fe-6f77-eb5f-9292-9b1c92f4f5bd@2ndquadrant.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1f9a76fe-6f77-eb5f-9292-9b1c92f4f5bd@2ndquadrant.com> User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Fri, Nov 22, 2019 at 01:21:31PM +0100, Peter Eisentraut wrote: > On 2019-11-05 22:16, Robert Haas wrote: > >First, I'd like to restate my understanding of the problem just to see > >whether I've got the right idea and whether we're all on the same > >page. When wal_level=minimal, we sometimes try to skip WAL logging on > >newly-created relations in favor of fsync-ing the relation at commit > >time. > > How useful is this behavior, relative to all the effort required? > > Even if the benefit is significant, how many users can accept running with > wal_level=minimal and thus without replication or efficient backups? That longstanding optimization is too useful to remove, but likely not useful enough to add today if we didn't already have it. The initial-data-load use case remains plausible. I can also imagine using wal_level=minimal for data warehouse applications where one can quickly rebuild from the authoritative data. > Is there perhaps an alternative approach involving unlogged tables to get a > similar performance benefit? At wal_level=replica, it seems inevitable that ALTER TABLE SET LOGGED will need to WAL-log the table contents. I suppose we could keep wal_level=minimal and change its only difference from wal_level=replica to be that ALTER TABLE SET LOGGED skips WAL. Currently, ALTER TABLE SET LOGGED also rewrites the table; that would need to change. I'd want to add ALTER INDEX SET LOGGED, too. After all that, users would need to modify their applications. Overall, it's possible, but it's not a clear win over the status quo.