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 1nbaJy-00011G-A0 for pgsql-hackers@arkaria.postgresql.org; Tue, 05 Apr 2022 03:57:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nbaJv-0006Oo-IW for pgsql-hackers@arkaria.postgresql.org; Tue, 05 Apr 2022 03:57:31 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nbaJv-0006Lu-5C for pgsql-hackers@lists.postgresql.org; Tue, 05 Apr 2022 03:57:31 +0000 Received: from mail-pf1-x436.google.com ([2607:f8b0:4864:20::436]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nbaJl-00045V-NY for pgsql-hackers@postgresql.org; Tue, 05 Apr 2022 03:57:29 +0000 Received: by mail-pf1-x436.google.com with SMTP id b13so10989271pfv.0 for ; Mon, 04 Apr 2022 20:57:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=3Vzo7pq4ZPXuqFWIIs1sgPKouLTEHpqn/giADoHLV/k=; b=q4ntMiXatamsQgKGXPnhDQ8l14sEccHpfXSsDrTqF2CXCFTcVoeNSCwFB+rkjRsj6N W7UWXo0KDkNjqqxJhMh4u10luHUpHFMnBYbXEeUw21yBbzGJV9acszELkAnAesNw/Hod wKGKo5vMhjFLHemG1chMpDRYqiRCnze59rZ32zSrzqQU8ZZkDCUttdWMEY3XXdGf5a7R eicVyEAKvCKS+JB5+m+Z8mtzfIr3sY7fflqRG1U6CLS+W2TLhmSEkpgHVOOjX02M+apc K3GIA+TWDBYvNRyHL+cP7M+TIBR9SntsAmz6on5ktJswNczn/EXg4F5xua9zXdyPWBxz 4hVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=3Vzo7pq4ZPXuqFWIIs1sgPKouLTEHpqn/giADoHLV/k=; b=RAbpZ++ntZYEaAd6/LxzNaGvQwt0gUpxgyvO8EozAoKL/X3ZlbbLS01ZqH6fci52HA WHmxl15zBMRPCzhtDVfxl0ND8aD4DCvLEgw/VPy5Jiw+TQX8h+sTGsZug3+pSJq0A5KK zMRczsswHsjTYp0UNQ2pquhobB4JZPKdGKdjSPi4K11m1qXK5AEozNEIAL2Gjqz57FH8 N0JAcVG1+himKzPS8HXlDE8UHhgL2VB47RzkdoC6CHIAjzC4+JcBoB4zcnqyKlNJIRtB r0WpZQTRM5i68+lIxsgpbEbWWgzkkstY1My81OBk+CTr+Hk2wHIO5r5/h90/PZITpI5q Mwjg== X-Gm-Message-State: AOAM5315/h47JdgjqppsINI2RmYDTLBVn7enkIB2kqyjd8YnJao4VEPZ u0MkkH3f4kXq31WYxpc9EVK1av2k0Ag= X-Google-Smtp-Source: ABdhPJwPR3YReKU8DWkFtxKVDuc+qMg3s5uc8qpHNuo6FEvtY9NLLgd3LGyoKgQnks0v3nXEq8m8OA== X-Received: by 2002:a05:6a00:3496:b0:4fa:e48e:3d02 with SMTP id cp22-20020a056a00349600b004fae48e3d02mr1684436pfb.26.1649131040593; Mon, 04 Apr 2022 20:57:20 -0700 (PDT) Received: from jrouhaud (2001-b011-1005-539c-040a-2f8a-d8ed-3fc9.dynamic-ip6.hinet.net. [2001:b011:1005:539c:40a:2f8a:d8ed:3fc9]) by smtp.gmail.com with ESMTPSA id y16-20020a17090a6c9000b001c993d935e7sm580381pjj.56.2022.04.04.20.57.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Apr 2022 20:57:19 -0700 (PDT) Date: Tue, 5 Apr 2022 11:57:14 +0800 From: Julien Rouhaud To: Masahiko Sawada Cc: gkokolatos@pm.me, Ranier Vilela , PostgreSQL-development , depesz@depesz.com Subject: Re: Showing I/O timings spent reading/writing temp buffers in EXPLAIN Message-ID: References: <2sAuEW1zGE4cTWCRPgzvAshfUAM44kW02tc3i31iLLCujLE-tczA8xOGFhs6c2EiEVM5uSQy_cJyvgAA1EKyxRtqnWM_mrirKwsTJ6Kxaaw=@pm.me> <20220119085236.iuuq4rtzm6qxvzls@jrouhaud> 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: Archived-At: Precedence: bulk On Tue, Apr 05, 2022 at 10:40:04AM +0900, Masahiko Sawada wrote: > On Tue, Apr 5, 2022 at 1:31 AM Julien Rouhaud wrote: > > > > Yes. In normal circumstances it shouldn't need a lot of time to do that, but > > I'm not so sure with e.g. network filesystems. I'm not strongly in favor of > > counting it, especially since smgrextend doesn't either. > > Good point. I think that adding a new place to track I/O timing can be > a separate patch so probably we can work on it for PG16 or later. Agreed. > I've attached updated patches, please review it. It looks good to me, just one minor thing in 002: @@ -183,8 +184,10 @@ typedef struct Counters int64 local_blks_written; /* # of local disk blocks written */ int64 temp_blks_read; /* # of temp blocks read */ int64 temp_blks_written; /* # of temp blocks written */ - double blk_read_time; /* time spent reading, in msec */ - double blk_write_time; /* time spent writing, in msec */ + double blk_read_time; /* time spent reading blocks, in msec */ + double blk_write_time; /* time spent writing blocks, in msec */ + double temp_blk_read_time; /* time spent reading temp blocks, in msec */ + double temp_blk_write_time; /* time spent writing temp blocks, in msec */ maybe the comments should respectively be data file blocks and temp file blocks. This is a minor detail and the rest of the patch looks good to me, so I'm marking the patch as Ready for Committer!