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 1pIpKf-0005dA-IR for pgsql-hackers@arkaria.postgresql.org; Fri, 20 Jan 2023 11:13:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pIpKe-0000yj-6N for pgsql-hackers@arkaria.postgresql.org; Fri, 20 Jan 2023 11:13:16 +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 1pIpKd-0000yP-Sg for pgsql-hackers@lists.postgresql.org; Fri, 20 Jan 2023 11:13:15 +0000 Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pIpKc-0000an-53 for pgsql-hackers@postgresql.org; Fri, 20 Jan 2023 11:13:15 +0000 Received: by mail-wm1-x334.google.com with SMTP id k16so3749680wms.2 for ; Fri, 20 Jan 2023 03:13:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=kre8Yoh4VkElKwJkZxVmNgGyHErtU6Qlw8xwbpnAdMI=; b=XBWpyEc0bghxumFT+dnD5Na/OWrD2GOM0SDqOeO1G1cCkVi+aTzCEt34tY3rf7962u TJjbiQ16WMBjXhZIgTL9Kk6xs/5FOONY82znQ/rv9HcsVAGILZCquJIByhU6OOaniZIi qLixbnty3DwJTxW5WZXRCkvOBsY424t+qzKbbXm6xU9BWWVt4d08G0+psCRp1jh8w2+A B4O14rHk/oDGiKyOiByXLrR9OxWsyOuLJg1QbSQum4Jz4okN4rOr4swI5g4tJ/m/QNn2 vm6nzShW/bmiBiEcZQCYeyaiIeJio8rKKnqTzkrLsE/zKf5hsMKnChwPkLFhOQE5IjG4 6CZw== 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:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=kre8Yoh4VkElKwJkZxVmNgGyHErtU6Qlw8xwbpnAdMI=; b=gcxOUwYFvLinxYe3lPCLCYtmcG2adlcJBUn3+G37I09UdiMS92jUeeRuWuwKJ4+SC/ aApz20VoyodcbxZxKDG8/EOPG3+iAtpWnZPVtVqstGGLsH6togRklT5F1i4Bm+v5YraV 160BAZeqxvl3J6uU+lPxia63c/uUve/2tJTsXuTcECDwUrT7awGVh0O7SlauybTv1gCv QN6moBiUZ27GWqKP8hMR9fncjszWVSkgpoTHg/n/ZxAgk8WWcgS5mNsVyZwBvuBBX9aa F5z3RKyYTejqdG/YYzhE8R0H1ABWBqSvaqdJYWKVuD5k4kMgNMbka9ZoMZ5BhMYL7r2C 5i2w== X-Gm-Message-State: AFqh2kqhbkK1Ke3yprsJ3jCpAKsrRa4Ta1yFfFrbklh8Dfd6ZjB+7i6j 3re/GFzItft9A9k8JtZcKgfjxnsgB5OdDH84cGS8B3O8aRfxwg+5AiThODVubumLY377bfDdgp0 ab5nwq1rF80qEJjHUVIEnoxSQpbdr8Epp1NTyjLnLeqFrPnFgM5eMukhOgN6NBWnPhk3XU8/lYK +lGkGtdSgUWe+2tzsxn7nwCVkQ/QMMyhOTVKRjkjxqdirDkDXaJV7QScine3dd8xiWAVoln3e4u +gIhe3OV6W9uI+ZRWGKHS3vAi7MynUtQFga X-Google-Smtp-Source: AMrXdXtGK4v7b/eHhaNYz/8g/E2YaAEmfwlPBTEr4871jNd6mX4n6Sd/JHnR3JffZCCjP4121SaEbA== X-Received: by 2002:a7b:cc07:0:b0:3da:fcb7:39e5 with SMTP id f7-20020a7bcc07000000b003dafcb739e5mr13198660wmh.23.1674213191931; Fri, 20 Jan 2023 03:13:11 -0800 (PST) Received: from [10.137.0.17] (static-84-42-175-93.bb.vodafone.cz. [84.42.175.93]) by smtp.gmail.com with ESMTPSA id q23-20020adfb197000000b002be5bdbe40csm1263794wra.27.2023.01.20.03.13.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 Jan 2023 03:13:11 -0800 (PST) Message-ID: <202f2f5e-2b1f-59b1-51db-8c6fa9490b6f@enterprisedb.com> Date: Fri, 20 Jan 2023 12:13:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? Content-Language: en-US To: David Geier , Pavel Stehule Cc: vignesh C , Lukas Fittl , Michael Paquier , Ibrar Ahmed , Maciek Sakrejda , Andres Freund , pgsql-hackers References: <20200612232810.f46nbqkdhbutzqdg@alap3.anarazel.de> <20220701172639.ty4iu5almspueriu@alap3.anarazel.de> <3eaeaa3a-b78e-ef0d-7319-5d713bbc09a0@gmail.com> <24aa958f-0463-03d4-ce54-20b277c954c6@gmail.com> From: Tomas Vondra In-Reply-To: <24aa958f-0463-03d4-ce54-20b277c954c6@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-CLOUD-SEC-AV-Info: enterprisedb,google_mail,monitor X-CLOUD-SEC-AV-Sent: true X-Gm-Spam: 0 X-Gm-Phishy: 0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 1/20/23 07:43, David Geier wrote: > On 1/18/23 13:52, David Geier wrote: >> On 1/16/23 21:39, Pavel Stehule wrote: >>> >>> po 16. 1. 2023 v 21:34 odesílatel Tomas Vondra >>> napsal: >>> >>>     Hi, >>> >>>     there's minor bitrot in the Mkvcbuild.pm change, making cfbot >>> unhappy. >>> >>>     As for the patch, I don't have much comments. I'm wondering if >>> it'd be >>>     useful to indicate which timing source was actually used for EXPLAIN >>>     ANALYZE, say something like: >>> >>>      Planning time: 0.197 ms >>>      Execution time: 0.225 ms >>>      Timing source: clock_gettime (or tsc) >>> >>> +1 >> >> I like the idea of exposing the timing source in the EXPLAIN ANALYZE >> output. >> It's a good tradeoff between inspectability and effort, given that >> RDTSC should always be better to use. >> If there are no objections I go this way. > Thinking about this a little more made me realize that this will cause > different pg_regress output depending on the platform. So if we go this > route we would at least need an option for EXPLAIN ANALYZE to disable > it. Or rather have it disabled by default and allow for enabling it. > Thoughts? > What about only showing it for VERBOSE mode? I don't think there are very many tests doing EXPLAIN (ANALYZE, VERBOSE) - a quick grep found one such place in partition_prune.sql. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company