Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wTjw4-000ixe-2O for pgsql-hackers@arkaria.postgresql.org; Sun, 31 May 2026 17:26:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wTjw1-007rMS-17 for pgsql-hackers@arkaria.postgresql.org; Sun, 31 May 2026 17:26:49 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wTjw1-007rMK-03 for pgsql-hackers@lists.postgresql.org; Sun, 31 May 2026 17:26:49 +0000 Received: from mail-yw1-x112c.google.com ([2607:f8b0:4864:20::112c]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wTjvw-00000000Vc6-2DkM for pgsql-hackers@lists.postgresql.org; Sun, 31 May 2026 17:26:48 +0000 Received: by mail-yw1-x112c.google.com with SMTP id 00721157ae682-7dc93d02916so32221227b3.3 for ; Sun, 31 May 2026 10:26:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780248401; cv=none; d=google.com; s=arc-20240605; b=DDRh03t91quBe1dvDJ29ih0rP5nOUgsGpbCy0EVjMzGI2nAfNfVSuLaUJdR0uJc6AD Q4CM9n1D7kp17LZGny95dS24uvRyXdMnF7r1sKt6eETCJQ/Bzcr8PWl0WDWY3f/eF4y5 TTT+kgLEj8NRUZ9DEO/Dve3x7GwFhoWewwiLyM6v4vJCvlQe9s/4ocDpqzr/CYE1XbCl n2mD/k+kvLSVi0we3avVPpOZrBrFKmq+Q5ebVPb3GjLnQ/sOdMQRinQfopfpArEHNAy9 5d3yRpV9iDjHOk8BKhtAHY3GuyR+rAtvSmMwT1g4olFDH0Y4MT71uUcHTutZuB1VyQy8 Xncg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:mime-version:references:in-reply-to:from :dkim-signature; bh=fhrZxAasCegZMNB9j1dNAKuoydEAz1os6ZTPMLW8vpg=; fh=nwNxTtLLPTU0ewfLM7SSbrjMajMl+wwnFkCY/fi90vE=; b=P9/P00RR4IG3veJ7I7YGFFYBw2ye7x8EMK7Sh7OhORTJX2VEvNW8kT8o/m6H28XyMz /hGG8/ZuotPU1qh+egzGj5rx5w1MWP5PSPkU9hWLBHAFAnSHPjojWudgWJnAKbSEsP2K DUx4HcfQnXORdI0JRmB2Y6Ifcl+TicwcxpUaDFcJ9B9Cz2LrpJ3HC82LmGlx7vMBKbB+ okYBgVCWu8/9qAaywE3uyeBktqvKLHdAWT2M6Z/TB+cy7vYxknXXTAWumTg2Yu8ZoFfw hTq6HDdGG1HUnP8v5OXaIfrqjJJTa2TscW+cX4/q1G/uFnHBJMVQnPo8LVjTijjyT0Ln ymjw==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=percona.com; s=google; t=1780248401; x=1780853201; darn=lists.postgresql.org; h=to:subject:message-id:date:mime-version:references:in-reply-to:from :from:to:cc:subject:date:message-id:reply-to; bh=fhrZxAasCegZMNB9j1dNAKuoydEAz1os6ZTPMLW8vpg=; b=Ae/7K7mZoskhbpgUsD6tmKPbAKMQbocSMx9WgDJ52YQQ1bXn9Pk1k0vTmQcNUiu5aq eXjV1IlsClKUmZRI5LrzEQNiL9dqpeETwcWn2zC1gS1Y15KjMD0cfsXK+c2BMvi+7+Uf YvwNu4HQmkforoeuz/3kcBheTyBn7ar5ygXcI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780248401; x=1780853201; h=to:subject:message-id:date:mime-version:references:in-reply-to:from :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=fhrZxAasCegZMNB9j1dNAKuoydEAz1os6ZTPMLW8vpg=; b=eniVgKk+dtGjDjyHlCZ+ePJoSD4z0aJTowmVjrkW/ok1llLtNkO4tHGqx17R8bkt/X wgtNj+bru5v4KL7t5zjK1wuNhQ1WQwfOuwV6eYPlqnsVz429b9J3ixdrXV8lfrgWY0Pv nHa3N4pZ5B/YuZ6rVJHaiTWFsf7vY0z6x9JyIKZCOfaHPWv7w3BqZLGG3Lnj7b8eXRPO AMXgJzqLf4RPZKZxKzIunT9NZitdVSDHO3H7vZTfdoYDZL3R3JhQNwTYLVZDYa2NESPG PDRXRZhpnWycB/5uGsu6kx3NoXDP7nfUHoQM6/6EZJf3Koet4aSns8LHFcE5JMt5fwS2 5jxg== X-Gm-Message-State: AOJu0YytTQAtyKsBcC6G91stsp7dy4qLPhAxc7x3S2FRAl6sLAaiAQMt FH0P48ztklV0YAwSsA1DfHVsm3rp+hFM9hxIpHJWvwX4BPb78w6CsTmGBLMVjjmzteJsKUU0Ced XxvkyuThzhiKsO3N9KHwWi+/73Usm54y6gV3ZmdWCqNoTH8R+zEMeaIy3RR5I3whUmdnRxMIKuF BgYYd4kcql++dkt7Mw3A3gj9I+BeugrKjMtlqWkOk4S0DRmn4S44VexH8bV2BpzW9y63RomDcMW o/a8csZDcRl+svgDo7XLXSOLWM60qCaPlY5H7mxXFr6ihqQ+Ou+gcizDDY0JGiWIQaPu7EK9u3Z iQ== X-Gm-Gg: Acq92OEbHYILwmjxY780VEAQprXnzqdbtIHo0foxbNR5ShaeOcUCmOLVRO5v67+DSkn 8q1BDFYbEK8tdBhcpc6Bza9d6qKR2CXFwWEna6BRBJQbgPrQlHUXyI3odLJJjZZU7VfCYIBDh+f Rd5BQgBDKNY+nOSX/XBSgzBldxkF7DU6R4w+z6XLsphJdGoouR48kXMvmU6yMek/BO4L9A/5z0l PJwEnfbOpHni4sYBnCcq6C4P+qk1imHmyXxF+adtk8NvK0be6e6RVyOQG/5ReJ47XKYg+gx1A76 hE3hpCb3wc40x53CWmTt64XQDQvxAIkr8vW30H2T20z2EC7b7BoGHh/6K9PFn2fBmjhlORWeWIj 4fBI= X-Received: by 2002:a05:690c:6902:b0:7dd:73e7:84d1 with SMTP id 00721157ae682-7e059fa7d6emr67622997b3.13.1780248401293; Sun, 31 May 2026 10:26:41 -0700 (PDT) Received: from 298783833264 named unknown by gmailapi.google.com with HTTPREST; Sun, 31 May 2026 10:26:40 -0700 Received: from 298783833264 named unknown by gmailapi.google.com with HTTPREST; Sun, 31 May 2026 10:26:40 -0700 From: Zsolt Parragi In-Reply-To: References: MIME-Version: 1.0 Date: Sun, 31 May 2026 10:26:40 -0700 X-Gm-Features: AVHnY4LRLHKqxv4oCOj90WSgzPoHmXC8ZXcHqsBnxGlfMBamBZ2bhb_CWP3fnu4 Message-ID: Subject: Re: Improve pg_stat_statements scalability To: pgsql-hackers@lists.postgresql.org Content-Type: text/plain; charset="UTF-8" X-CLOUD-SEC-AV-Sent: true X-CLOUD-SEC-AV-Info: percona,google_mail,monitor X-Gm-Spam: 0 X-Gm-Phishy: 0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hello! I noticed that the patch has some issues with minmax_only, and these differences seem to be unintended to me: 1. minmax only resets updates mean/sum_var_time (but then when it calculates them again, it also uses the data before the minmax reset) + /* + * Reset only min/max timing values and update minmax_stats_since. + * Iterate matching entries in the dshash, reset the corresponding + * pgstat counters' min/max fields. + */ ... + shared->counters.mean_time[kind] = 0; + shared->counters.sum_var_time[kind] = 0; 2. min_time doesn't recover after a minmax reset: + if (pending->min_time[kind] < shared->min_time[kind]) + shared->min_time[kind] = pending->min_time[kind]; As it is only updated if it's smaller, but it is 0 after it, and because the call count remains > 0 it doesn't get initialized with the current value. + if ((int) pg_atomic_read_u64(&pgss_shared->nentries) <= pgss_max * (100 - USAGE_DEALLOC_PERCENT) / 100) + break; isn't there a possible overflow here? The similar deleted check had explicit uint64 casts for pgss_max multiplication. - /* - * Don't proceed if file does not exceed 512 bytes per possible entry. - */ - if ((uint64) extent < (uint64) 512 * pgss_max) - return false;