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 1pK0XY-0000O4-Qg for pgsql-hackers@arkaria.postgresql.org; Mon, 23 Jan 2023 17:23:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pK0XW-0008BY-M4 for pgsql-hackers@arkaria.postgresql.org; Mon, 23 Jan 2023 17:23:26 +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 1pK0XW-0008BP-BD for pgsql-hackers@lists.postgresql.org; Mon, 23 Jan 2023 17:23:26 +0000 Received: from mail-qt1-x829.google.com ([2607:f8b0:4864:20::829]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pK0XU-00032F-3U for pgsql-hackers@postgresql.org; Mon, 23 Jan 2023 17:23:25 +0000 Received: by mail-qt1-x829.google.com with SMTP id d16so10197912qtw.8 for ; Mon, 23 Jan 2023 09:23:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=/U0oZSrrsn614IfQSokx3n8GEiTxaeubdUAtWHRuUpw=; b=oMnujBVymCHumVvxMzOmpccC+dd/lSUvJj6u2g7myC+qn1O120T2Q1drOUADStc4oU VglRvhEN4x9qqaNg0GUY4JLyrpN6oFswst2gqCOus937Eknjq2uZumeTiNpgeYp3JEFZ trzL0tYkJi8Z9RFGv6YEIFNjTJYXS5A3YZJ01QN6m1NxWi+gA5riAJ/eA06JRPR6AdW6 YhpAwZGdRfc0AufPg4FuPc0v+SHXZRJTabxH1u7CCMTqC77/cVUqxS3Xwl3a3uvRImMq cjd5PkwbzXYIqP24chJdiqAWK2lFEMUKBO2UeNQDnk68OOPKIjYmnKP675P8wegRz0S2 3nAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=/U0oZSrrsn614IfQSokx3n8GEiTxaeubdUAtWHRuUpw=; b=glbpeQCNYNKkaMTmcnRNnC8eHFwobyLj6GZcnC5AP/QAYYSnAuLqTyuOtlYXnbqwC9 AP6oKEaQwGxDdbvgYOCbhpdsCAan7/ubK+sHzM1ifElurWKOEuNFeg9qnhEGELch+eIw 7ElAJeOqKiDh6yERGT6+YZ7T7kUJbnjyCopX+YUeKE6Rhj081heg/qYVXfO3yHoIeHs5 NmG1UguoYoASkWZ13Py8mmZ6/qcsLqTZgogWwXsAqykza8KCY4XCPMVrHk6j4MRb5OID RpQo6I5dDBUQWg7Ibd8dqd4IHWR98ENG+7o1PUSrZlU9wfdTMEwSzxEee1kGWVnMBB2x 98IQ== X-Gm-Message-State: AFqh2kqBHh1LXbOR9xRO5ZSOBM4HQCaoLPZNQKDd7/eyiuLtLu22y56w oJ3+xlYfMXUkwbvCk5Qud4Q= X-Google-Smtp-Source: AMrXdXsWZWDhJPHSlNcGtCXqio1NFDawoQeeezeI6dcEXHcTFqyyFOJ4y0FZdPGow8zHYJPTri+VRg== X-Received: by 2002:ac8:470a:0:b0:3b6:4217:3db2 with SMTP id f10-20020ac8470a000000b003b642173db2mr34179597qtp.13.1674494602592; Mon, 23 Jan 2023 09:23:22 -0800 (PST) Received: from [172.16.209.129] (vip-148-139-0-229.cust.service-now.com. [148.139.0.229]) by smtp.gmail.com with ESMTPSA id b5-20020ac812c5000000b003b63dfad2b4sm9927107qtj.0.2023.01.23.09.23.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Jan 2023 09:23:22 -0800 (PST) Message-ID: Date: Mon, 23 Jan 2023 18:23:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? To: Andres Freund Cc: Pavel Stehule , Tomas Vondra , vignesh C , Lukas Fittl , Michael Paquier , Ibrar Ahmed , Maciek Sakrejda , pgsql-hackers References: <3eaeaa3a-b78e-ef0d-7319-5d713bbc09a0@gmail.com> <24aa958f-0463-03d4-ce54-20b277c954c6@gmail.com> <20230121041439.zraxavau2wqf2ys3@awork3.anarazel.de> Content-Language: en-US From: David Geier In-Reply-To: <20230121041439.zraxavau2wqf2ys3@awork3.anarazel.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On 1/21/23 05:14, Andres Freund wrote: > The elapsed time is already inherently unstable, so we shouldn't have any test > output showing the time. > > But I doubt showing it in every explain is a good idea - we use instr_time in > plenty of other places. Why show it in explain, but not in all those other > places? Yeah. I thought it would only be an issue if we showed it unconditionally in EXPLAIN ANALYZE. If we only show it with TIMING ON, we're likely fine with pretty much all regression tests. But given the different opinions, I'll leave it out in the new patch set for the moment being. -- David Geier (ServiceNow)