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 1jLN2Q-000160-Hj for pgsql-hackers@arkaria.postgresql.org; Mon, 06 Apr 2020 08:23:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jLN2P-0003dz-Bv for pgsql-hackers@arkaria.postgresql.org; Mon, 06 Apr 2020 08:23:21 +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 1jLN2P-0003dj-2N for pgsql-hackers@lists.postgresql.org; Mon, 06 Apr 2020 08:23:21 +0000 Received: from mail-lj1-x244.google.com ([2a00:1450:4864:20::244]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jLN2I-0007Hq-Ks for pgsql-hackers@postgresql.org; Mon, 06 Apr 2020 08:23:20 +0000 Received: by mail-lj1-x244.google.com with SMTP id p14so13643365lji.11 for ; Mon, 06 Apr 2020 01:23:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=GYuGF0fjJBEY6oE8aopDjE9Yt8aykG6QDxKaQgLLiLU=; b=WaopQ1Y6AjFvN6MwQeBu6cIUvMyE4N9nL0ex+9sHXwgV+GngmmHlBlvVALdxm03CUh U0szfBc993+OvLxnEqCXOFrXeTT4Xed5QKbU3XwpbH5i1i3VCRlrnKH3NIT/I7S6yOld 8BKVs8ZQb20kSli3b3gtFMkLPxH5mC5zycVYNNZps7gOlw7Y+PeuZjPWkY/joI32d1Mz mybGbj/GGFeed5dy9/7xyDlE0v1y3cZLPCUj+V0mppQ9e5iWnn9GX48wFnKtYKjXFU0h 3tTjELvbbhY3EnF4g8ka9/Yyz4+HF0D3QUuTG+czMUyuJR63BRvxE5KOQSgMgaHFQK9k zk0w== 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; bh=GYuGF0fjJBEY6oE8aopDjE9Yt8aykG6QDxKaQgLLiLU=; b=GSC6jvbP0w/OESne7eGM7XD3/+lELH6EV0+sZDlD1Ec9EVivru19QsCO8Irx5zsqPa YFefbxojslW0TSs1i1keRAPhaggRrS/TbUXGpsyIMv22kXcLdwlyjMYJ5AVktdmkzC/p 5bc2+S+YjgIPxEdA9D38yAe5PmbSrnm67urNPhMFcIHLWHtO8dBZycx8Ngxxlkd3Z85G 7IV9wZgfYFVuFnF9TMQtHE47g8YwuMVmN7zAeDLdCq5jM9Ctuvd8Dz660MpyBuB4MamN bV5xiwEUvTLcS423VKFlqVmP7l0LakRZoFJfjs9Hk7KIzz3MuouBew62hBJeOJUtzFbz 0/pQ== X-Gm-Message-State: AGi0Pub/qs56oHExdU12VquthBYWugM8pZxikOJPGnDXZzc7gLqljtn5 Mcx19//Im02g5+CEmdE4vXsuXtRG8bI= X-Google-Smtp-Source: APiQypJiHYSSpF8PmzuCOUUdgkXdQQ0PqTpUrG/vR4gLxrbuuPiSnbd0MniLNLECq31hcJsfCghl1A== X-Received: by 2002:a2e:89c5:: with SMTP id c5mr10968233ljk.48.1586161392365; Mon, 06 Apr 2020 01:23:12 -0700 (PDT) Received: from nol (82-64-124-11.subs.proxad.net. [82.64.124.11]) by smtp.gmail.com with ESMTPSA id b16sm9384935ljh.20.2020.04.06.01.23.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Apr 2020 01:23:11 -0700 (PDT) Date: Mon, 6 Apr 2020 10:23:07 +0200 From: Julien Rouhaud To: Amit Kapila Cc: Dilip Kumar , Kuntal Ghosh , Fujii Masao , Kirill Bychik , PostgreSQL Hackers , Thomas Munro Subject: Re: WAL usage calculation patch Message-ID: <20200406082307.GI1206@nol> References: <20200404060303.n2q74lbccjm2swdc@nol> <20200404085423.GC1206@nol> <20200404092015.GE1206@nol> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Mon, Apr 06, 2020 at 08:55:01AM +0530, Amit Kapila wrote: > On Sat, Apr 4, 2020 at 2:50 PM Julien Rouhaud wrote: > > > I have pushed pg_stat_statements and Explain related patches. I am > now looking into (auto)vacuum patch and have few comments. > Thanks! > @@ -614,6 +616,9 @@ heap_vacuum_rel(Relation onerel, VacuumParams *params, > > TimestampDifference(starttime, endtime, &secs, &usecs); > > + memset(&walusage, 0, sizeof(WalUsage)); > + WalUsageAccumDiff(&walusage, &pgWalUsage, &walusage_start); > + > read_rate = 0; > write_rate = 0; > if ((secs > 0) || (usecs > 0)) > @@ -666,7 +671,13 @@ heap_vacuum_rel(Relation onerel, VacuumParams *params, > (long long) VacuumPageDirty); > appendStringInfo(&buf, _("avg read rate: %.3f MB/s, avg write rate: > %.3f MB/s\n"), > read_rate, write_rate); > - appendStringInfo(&buf, _("system usage: %s"), pg_rusage_show(&ru0)); > + appendStringInfo(&buf, _("system usage: %s\n"), pg_rusage_show(&ru0)); > + appendStringInfo(&buf, > + _("WAL usage: %ld records, %ld full page writes, " > + UINT64_FORMAT " bytes"), > + walusage.wal_records, > + walusage.wal_num_fpw, > + walusage.wal_bytes); > > Here, we are not displaying Buffers related data, so why do we think > it is important to display WAL data? I see some point in displaying > Buffers and WAL data in a vacuum (verbose), but I feel it is better to > make a case for both the statistics together rather than just > displaying one and leaving other. I think the other change related to > autovacuum stats seems okay to me. One thing is that the amount of WAL, and more precisely FPW, is quite unpredictable wrt. vacuum and even more anti-wraparound vacuum, so this is IMHO a very useful metric. That being said I totally agree with you that both should be displayed. Should I send a patch to also expose it?