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 1p0DC1-0007NL-Vn for pgsql-hackers@arkaria.postgresql.org; Wed, 30 Nov 2022 02:51:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1p0DC0-0002CH-33 for pgsql-hackers@arkaria.postgresql.org; Wed, 30 Nov 2022 02:51:24 +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 1p0DBz-0002C7-L4 for pgsql-hackers@lists.postgresql.org; Wed, 30 Nov 2022 02:51:23 +0000 Received: from mail-il1-x12a.google.com ([2607:f8b0:4864:20::12a]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1p0DBs-0002Mi-EB for pgsql-hackers@postgresql.org; Wed, 30 Nov 2022 02:51:22 +0000 Received: by mail-il1-x12a.google.com with SMTP id h17so7571702ila.6 for ; Tue, 29 Nov 2022 18:51:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20210112.gappssmtp.com; s=20210112; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=9CYO++S1RPp6JGx9oQIgUPpcVzwgI8XHl+JC95dmwp0=; b=3JTNd9UF/zdJWpBOzOjZfja7U/JaEsLuMtV7Fccnuciuk8GKvqLvdfwjdY9C8q1Ny2 CIoXVx+LcmQMlN/lkHDtM3rUCiOkkLch3jniNDJub+ZjMmF2VpSQfChNXKVdkWTcVh55 vlkIT101Wjqn4LnQSo7U5HLXH/32jhhUbGTK1oTRCqo+Yif2yVGnVptZZ+mbA0hCtMBH ePvqWb26mTMhdQ/BDCY6fdcbYA80gWub5IZxbIGNzGznxPPIG3tOa+JQu3s3YEXLY+gs mv3ZJKzIspL634TuFUr6ziHhRxMdqRRqoWPYcPpwOGJnnwPzBCL7G7avnxa2i0JvSTbg Pw6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=9CYO++S1RPp6JGx9oQIgUPpcVzwgI8XHl+JC95dmwp0=; b=ODQdAV6t3xxTJ+Ee1Q2Fr06Qw/QRq3Y71rUElLKhiApaLNNkbME7W1IUOwINhmpCvg yQtRGD/T6pjRcAzh1cQ0NHUtPAG5bEXzalv3gXxbvMKA89cfYv7UPlrmBURY1EN3SzNk ta5t/JDchPidOrtrHDPPb+ui/S9slZlWrvaMnA5AG/NjSEJDlKmh/fjE+VzBROZbR1Yh hKZ2C7W8g7VcM4OzfesBqgE/QrwkaKgysEW2hwouvUVMYV5QExxP0KSxaKN4odDVsk3w jHn5geNJ63t4JilT9W2u56AoqWQHfXTU9NDGpvUk1Vrbro9L7mDNsUL5uwHBVL4Wrblc QlJw== X-Gm-Message-State: ANoB5pnyQKaKewb0KEMpU4kLA3XaK+5dz1U/Y1oGpb63qrBuxb8bM7vp CK33qnHUTIFItee6KZMNibRoPw== X-Google-Smtp-Source: AA0mqf48hHQBpPUxfEmnqrk0o7vxVQfyYtmgloZmBv+G72RxqiFrZT4dCADiowsrKSUjIRlW+LmQJA== X-Received: by 2002:a92:1903:0:b0:2ea:e57a:e589 with SMTP id 3-20020a921903000000b002eae57ae589mr20170062ilz.240.1669776674685; Tue, 29 Nov 2022 18:51:14 -0800 (PST) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id m16-20020a0566022e9000b006dfbfec899esm108670iow.28.2022.11.29.18.51.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Nov 2022 18:51:14 -0800 (PST) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 53409800CEB; Tue, 29 Nov 2022 20:51:13 -0600 (CST) Date: Tue, 29 Nov 2022 20:51:13 -0600 From: Justin Pryzby To: Melanie Plageman Cc: Maciek Sakrejda , Andres Freund , Lukas Fittl , Alvaro Herrera , Kyotaro Horiguchi , Magnus Hagander , Pg Hackers , Thomas Munro Subject: Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?) Message-ID: <20221130025113.GD24131@telsasoft.com> References: <20221020173101.32d2is2ldsdym7jl@awork3.anarazel.de> <20221123054329.GG11463@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 Mon, Nov 28, 2022 at 09:08:36PM -0500, Melanie Plageman wrote: > > +pgstat_io_op_stats_collected(BackendType bktype) > > +{ > > + return bktype != B_INVALID && bktype != B_ARCHIVER && bktype != B_LOGGER && > > + bktype != B_WAL_RECEIVER && bktype != B_WAL_WRITER; > > > > Similar: I'd prefer to see this as 5 "ifs" or a "switch" to return > > false, else return true. But YMMV. > > I don't know that separating it into multiple if statements or a switch > would make it more clear to me or help me with debugging here. > > Separately, since this is used in non-assert builds, I would like to > ensure it is efficient. Do you know if a switch or if statements will > be compiled to the exact same thing as this at useful optimization > levels? This doesn't seem like a detail worth much bother, but I did a test. With -O2 (but not -O1 nor -Og) the assembly (gcc 9.4) is the same when written like: + if (bktype == B_INVALID) + return false; + if (bktype == B_ARCHIVER) + return false; + if (bktype == B_LOGGER) + return false; + if (bktype == B_WAL_RECEIVER) + return false; + if (bktype == B_WAL_WRITER) + return false; + + return true; objdump --disassemble=pgstat_io_op_stats_collected src/backend/postgres_lib.a.p/utils_activity_pgstat_io_ops.c.o 0000000000000110 : 110: f3 0f 1e fa endbr64 114: b8 01 00 00 00 mov $0x1,%eax 119: 83 ff 0d cmp $0xd,%edi 11c: 77 10 ja 12e 11e: b8 03 29 00 00 mov $0x2903,%eax 123: 89 f9 mov %edi,%ecx 125: 48 d3 e8 shr %cl,%rax 128: 48 f7 d0 not %rax 12b: 83 e0 01 and $0x1,%eax 12e: c3 retq I was surprised, but the assembly is *not* the same when I used a switch{}. I think it's fine to write however you want. > > pgstat_count_io_op() has a superflous newline before "}". > > I couldn't find the one you are referencing. > Do you mind pasting in the code? + case IOOP_WRITE: + pending_counters->writes++; + break; + } + --> here <-- +} -- Justin