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 1pI7vL-0008Of-Q2 for pgsql-hackers@arkaria.postgresql.org; Wed, 18 Jan 2023 12:52:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pI7vK-0000rr-F4 for pgsql-hackers@arkaria.postgresql.org; Wed, 18 Jan 2023 12:52:14 +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 1pI7vK-0000rC-1S for pgsql-hackers@lists.postgresql.org; Wed, 18 Jan 2023 12:52:14 +0000 Received: from mail-ed1-x52a.google.com ([2a00:1450:4864:20::52a]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pI7vE-000786-HG for pgsql-hackers@postgresql.org; Wed, 18 Jan 2023 12:52:12 +0000 Received: by mail-ed1-x52a.google.com with SMTP id b4so29973913edf.0 for ; Wed, 18 Jan 2023 04:52:08 -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=ucNjB5wr7KjNtr1A+lPBl6vdciKEAfUMyis10ZXEJbE=; b=IP2yY9+JzvuUxpXNxt5OwyZIi68oAP9nS6zgoU9HdO5oEiieITB0ZkDTKKlFlrOD+i vto+2dvQ1jXpXgQ+xWrxZt+GvakVCoaoM4iuOGI0mPsd+UNlpI5ykXZ/AcpEThdKttr1 4bquQ+u4X6yHATadgk95F792jFDbgUwHlNP/hN8o9MQkc2jjxlQyqAH6vVRnboEZF1SC NaCUMEpIpfscjj8XcXU0Ype8KwC+hIqjq8dQk7ItDmjo129XWvpHCjlh5Lao5t3Tl0pL H21GSh3ISDwrwxgTwvzUBg9mitQjDhIm1ndGDXFpi3yWEIYx6rk21qdotYXJhdxbLr11 Zgbw== 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=ucNjB5wr7KjNtr1A+lPBl6vdciKEAfUMyis10ZXEJbE=; b=ICpiNPk9g0ZWT1QeAid3BSwoRmIgvsGAnReHvrMiufmnDuz7JZdZzCUVr5Ix3FRy/d nGFyzJR+BYEVB40sWp5n1UzuTD+fAVpV6eESNNY/Iz0+huf7btNJ4ajQnoFkhDbQPNdg aMPVfH4QjJaSqfnvudPd0qqbFL9uahBsqDXOtd4wexaoNaMunKQG4xX62KJtTzxuqbJ8 Swik1iab2oL3czgOSrUVvrbRIdXU8jhLyKjHV8STMtyQLKhTp7U73bty7X29/hHyPTAE TcTOOokenhWeJvd9wt4h3q3i901TLw9zH/9Aj2fAqMANIz8wDfB9zD0QxrGyVpPFSWzS rWMQ== X-Gm-Message-State: AFqh2kpJOcMwmlQKlFYp+yoM+NysxJBTojINFYp0ffSeQsezghqRsLGd /MJ2xQgRR1HjwG7uGwY0QCE= X-Google-Smtp-Source: AMrXdXvCoMj0hMRx+Tfyc6J8QX01DTPcFDGhAmcY9KTHiDfKdAqvd7qlC9kckXTFdkbtAehInzwPIg== X-Received: by 2002:a05:6402:2907:b0:49e:498c:5e34 with SMTP id ee7-20020a056402290700b0049e498c5e34mr2286429edb.31.1674046326834; Wed, 18 Jan 2023 04:52:06 -0800 (PST) Received: from [172.16.209.129] ([147.161.235.10]) by smtp.gmail.com with ESMTPSA id kw4-20020a170907770400b0084d397e0938sm13270582ejc.195.2023.01.18.04.52.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 Jan 2023 04:52:06 -0800 (PST) Message-ID: Date: Wed, 18 Jan 2023 13:52:05 +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: Pavel Stehule , Tomas Vondra 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> Content-Language: en-US From: David Geier In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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) > > There has been a proposal to expose this as a GUC (or perhaps as > explain > option), to allow users to pick what timing source to use. I > wouldn't go > that far - AFAICS is this is meant to be universally better when > available. But knowing which source was used seems useful. > > > +1 Thanks for looking at the patch. I'll fix the merge conflict. 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. -- David Geier (ServiceNow)