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.94.2) (envelope-from ) id 1uGjYf-006ayu-3F for pgsql-general@arkaria.postgresql.org; Sun, 18 May 2025 19:20:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uGjYe-00BPxx-55 for pgsql-general@arkaria.postgresql.org; Sun, 18 May 2025 19:20:24 +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.94.2) (envelope-from ) id 1uGjYd-00BPxp-P6 for pgsql-general@lists.postgresql.org; Sun, 18 May 2025 19:20:23 +0000 Received: from mail-yb1-xb35.google.com ([2607:f8b0:4864:20::b35]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uGjYa-002Xsi-14 for pgsql-general@lists.postgresql.org; Sun, 18 May 2025 19:20:22 +0000 Received: by mail-yb1-xb35.google.com with SMTP id 3f1490d57ef6-e733cd55f9eso3475311276.1 for ; Sun, 18 May 2025 12:20:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=atlassian.com; s=google; t=1747596018; x=1748200818; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=KmqUztnYz/pkpzq2o5gYYNYzBnl0bgZ2ag9E8mEvsic=; b=KX5KgNMgabThWtlC/rIcQi5npYtVKdpR9ww78eZqHbFiiZOd/Co0IFwa+FV28myPh6 X0CM7UtsH9Qq4dMYEnfYYcXw6l+izlkTsR0JOPfORmwsK3u3RiFFpBw8tRRAAS1eiFPO nS545mqgP9bO5SqTuMh1BEnqRiMDgh9GXUuWdyn+rbNQ4bLQDg6ScEEY/djMgDlXGgHR McHNC9v7RTaOPeIyX9c00x7iJNcHp5M1UQpVnmceczEZBgQAYyPpWyn81k0h/+20++vd nRCI7+NC+HTnTqO7mKUmNEkpUIFJ6NW27grfUfVpHjAncH82odJOGUK1IbyuutpLY/Qk YXYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747596018; x=1748200818; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=KmqUztnYz/pkpzq2o5gYYNYzBnl0bgZ2ag9E8mEvsic=; b=I50Ah8WrpiEDRh9t5UG9TMWbWjhWZJ5Pm2XsYCTYKeNLXFEa8sJ7HucE5f8UV9nxv/ hdqfGvBWUYbA94WEdWuhCu2gGJE//4dcKCL5BAMJq5qHzR3WDR7QeSzaxlmQjLMgM69Y 1vRRJggFqOM3BcvZqe1Kc++iGHN5FD0bxamUUPl9uXae+6o6w8ygmOkiV3Z1IGUnJbji dM7mIslD5Z45gV60Lb6wzqlp2cKyOciRtiDz8Mt52+rim5SQoIiq/6ngrD0X8jbCAfWN USXrCUDQb6UXIvN2uxIV64aAe7gPb8lOz9myESnj2XapiXvu56STUjjutkE2crlrDew8 P+tA== X-Gm-Message-State: AOJu0Yy9W6d06EEIGKlVnQ7OU0/bEc5BsAdeoZaiUIoUACFv4IH36sWp Cd/dZpkvsQ65dtkwsF8j2dTj52nWWV6ek0w0fREnUJPwtVQwWDo1RitBMrjqQLnwyC+PlzsiERf H5PHdt8gs/r9j46p+QWCVcztGnYQUcOqio655lGULj0k7L8dNjVswMw== X-Gm-Gg: ASbGncvpaQrz1uobTTOW8odJNI5E6yScf5iSGjfAibeokVNQp33O68qlCocHNu0+viX qhaD7LroYHz6OkQbNNEAqAtiihURd6AHQVd93qycDBJp0389Yy1tppWr4PHawbH1rGnA/EXmhFF NPx7NlnSTRIQKFNqLk5st+DE6zejF5KdTFWKVX/2D+3zpoHb6SZnWeYyFJH04= X-Google-Smtp-Source: AGHT+IGsS8mUfECvUvA3iaH7bhb8SvcG7/S9qGrf9h0NkH0xTpkJabCZR+5/IqRAruWqsrc/TmF9hQXDHcM2aAnWLXk= X-Received: by 2002:a05:6902:4610:b0:e78:e283:9432 with SMTP id 3f1490d57ef6-e7b6a31742emr15018297276.39.1747596017763; Sun, 18 May 2025 12:20:17 -0700 (PDT) MIME-Version: 1.0 From: Jevon Cowell Date: Sun, 18 May 2025 15:20:07 -0400 X-Gm-Features: AX0GCFvCZoZBF5Z4oeHnBa9v23g8iVPJ5EgJ9Wb3hpiuft4SpAKyInYbGjVx548 Message-ID: Subject: pg_stat_statements has duplicate entries for the same query & queryId To: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000d9acc406356de737" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000d9acc406356de737 Content-Type: text/plain; charset="UTF-8" Hi Folks! Let me know if there's a better mailing list to ask this in. I have a statistics collector that collects data from various postgres statistics tables, pg_stat_statements being one of them. This is done on an entire fleet of Postgres databases. From the collected data we record the timestamp of each collection in the query itself as extract(epoch from now()) as ts. What I'm seeing is that for the same query *and* query id, there are two rows with different statistics data *at the same time*. For example one row can have 2 calls while another can have 4. Anyone else run into this or have any idea why this can occur? Regards, Jevon Cowell --000000000000d9acc406356de737 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Folks!
Let me know if there's a bett= er mailing list to ask this in.

I have a statistic= s=C2=A0collector that collects data from various postgres statistics=C2=A0t= ables, pg_stat_statements being one of them. This is done on an entire flee= t of Postgres databases. From the collected data we record the timestamp=C2= =A0of each collection in the query itself=C2=A0as=C2=A0=C2=A0extract(epoch from now()) as ts. What I'm= seeing is that for the same query and=C2=A0query id, there are two = rows with different=C2=A0statistics data at the same time. For examp= le=C2=A0one row can have 2 calls while another can have 4. Anyone else run = into this or have any idea why this can occur?=C2=A0

Regards,
Jevon Cowell
--000000000000d9acc406356de737--