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 1u8JKo-000lNY-QJ for pgsql-general@arkaria.postgresql.org; Fri, 25 Apr 2025 13:43:19 +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 1u8JKm-00BKsn-Uw for pgsql-general@arkaria.postgresql.org; Fri, 25 Apr 2025 13:43:17 +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 1u8JKm-00BKpH-Fi for pgsql-general@lists.postgresql.org; Fri, 25 Apr 2025 13:43:17 +0000 Received: from mail-vk1-xa35.google.com ([2607:f8b0:4864:20::a35]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1u8JKj-0020ls-1S for pgsql-general@lists.postgresql.org; Fri, 25 Apr 2025 13:43:16 +0000 Received: by mail-vk1-xa35.google.com with SMTP id 71dfb90a1353d-527b70bd90dso1033253e0c.3 for ; Fri, 25 Apr 2025 06:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mokadb-com.20230601.gappssmtp.com; s=20230601; t=1745588592; x=1746193392; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=kFBMzF8+jJiROkRbZdYBCZuiub5Cn0izEKYYTwH4uAo=; b=Gn+dGgn27Jezk1IwVrbVRLfGwiEpfebJog4CCsPTr4OAJZfJvaoovA423J6R+sYewb 9lHYKfHqtxIq0NvwbookcbxnEjWUq0jJzEPa9Qy9UEq1GvTh8b1JqzqWgHB+tdEzUI31 e+J3gUUbG5HLL/FDMdGwEAyhylTeSsAKS3rhffbpAclLJMgrl7oL6CXxd4o5xToobnvj fRKVKiYFOuNC+YBuFEvuwZ/OsnWWMRNFGFQS4wu4F1eeCChQGyNOnljxIuHECPdDr/jg iFggT1tLNNqV/t4W091c7+O5ZZ5L6JlUMXgyXd/KEYy5GwGGMelLwQTej7YZUaaamY+D Nd1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745588592; x=1746193392; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=kFBMzF8+jJiROkRbZdYBCZuiub5Cn0izEKYYTwH4uAo=; b=tA0UXHbnIhgVjVxPlGkxwk4RoDFhrpb/4kMbu3BisGit/Vhj0kjowEzFjS58QSkIas DaLtcasd0I0jJF87dyWoRh9QaI2uLgTHmLnqu9RuhjCccqascJzQlizk639WL/RghFtm KWTvMAnnPKv16/vtx+T2fQfWksZbWhXt5qY6POPG3b3xxNiFUYkifl9gpBjQcl6hFKBZ ONFJ7Y9bJQEX1UqyVFS4QIkyRpw381Pu/eOZ74cWKgJSsmn8hiicLQoI1OWNe6cxn0UT R8c2PnvFi82gLxBIPRLp2bYFhq4PW4W08wpZMrwCNQWUO2dfo1MP/PVvSvhzpzRlH1pz Xiwg== X-Gm-Message-State: AOJu0YxfjV7HkPccO0TZQg1VLseJfMKGNrA4ElVEAL+2MnFZPxxOerTg gpYsIEAEIuXdcF0TwtdJySUyRwU54tay25sYMkY/WSU49/BV3uLwwmlIpmceUMcrNdmDrTUZg4e kNqBgWFbO6d5J85pSFvuFFMRuKg5XeDFUe/Rw7Luc5uGT63lD X-Gm-Gg: ASbGncshDFvpFb0wk9mlmkQ2VYy4Z7WL7LaaN5p1iz5A1XMkT4xDqHmvuCjIbcYdOTU gE2Vepdha1M46FdiNH9l0ctUHsZJpUV35EGzlwex6nQEp8GUr1RAO27yWfZuytK0QpXkd3/i4yJ d+Kk7NlLwGrK4M2IWKaMRXfA== X-Google-Smtp-Source: AGHT+IEeWojq1PUfiZYawVG1BgyD8JWi6cSqMOgYJh5R+71P88tvhWiGFv29MCWLTZwBqUNkefeyfxIkfBYehntSsOE= X-Received: by 2002:a05:6122:d04:b0:529:b2:ea5e with SMTP id 71dfb90a1353d-52a89d355abmr1558815e0c.2.1745588592059; Fri, 25 Apr 2025 06:43:12 -0700 (PDT) MIME-Version: 1.0 From: Marc Millas Date: Fri, 25 Apr 2025 15:42:59 +0200 X-Gm-Features: ATxdqUHiZZUsK6Y_chN3S6zHnEzVb-khG_XoRT4scBDgePl8koXScbnOoUP26ME Message-ID: Subject: shared buffers To: "pgsql-general@lists.postgresql.org" Content-Type: multipart/alternative; boundary="000000000000f4468c06339a8390" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000f4468c06339a8390 Content-Type: text/plain; charset="UTF-8" hello, got something strange to me: Same db ie. same data, around 1.2TB,one on pg13, one on pg16 same 16 GB of shared_buffers, I am the single user. both have track_io_timing on on pg13, if I run a big request with explain (analyze,buffers), I see around 6 GB read if I do rerun the very same request, no more read(s), all data in the shared buffers cache. fine If I check with pg_buffercache what's in it, I see the biggest tables of my request within the biggest users (in number of blocks used). All this is fine. next, if I do the very same on the pg16 machine, whatever the number of times I rerun the explain (analyze, buffers) of the same request, each time, the explain shows the same volume of reads. again and again. If I check with pg_buffercache, the set of objects stay the same, WITHOUT the objects of my request, just like if those objects where sticky. any idea ? thanks Marc MILLAS Senior Architect +33607850334 www.mokadb.com --000000000000f4468c06339a8390 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
hello,

got something strange= to me:
Same db ie. same data, around 1.2TB,one on pg13, one on p= g16
same 16 GB of shared_buffers,
I am the single user.=
both have track_io_timing on

on pg13, i= f I run a big request with explain (analyze,buffers),=C2=A0
I see= around 6 GB read
if I do rerun the very same request, no more re= ad(s), all data in the shared buffers cache. fine
If I check with= pg_buffercache what's in it, I see the biggest tables of my request wi= thin the biggest users (in number of blocks used). All this is fine.
<= div>
next, if I do the very same on the pg16 machine, whateve= r the number of times I rerun the explain=C2=A0(analyze, buffers) of the sa= me request, each time, the explain shows the same volume of reads. again an= d again.
If I check with pg_buffercache, the set of objects stay = the same, WITHOUT the objects of my request, just like if those objects whe= re sticky.

any idea ?

tha= nks

Marc= MILLAS
Senior Architect
+33607850334

--000000000000f4468c06339a8390--