public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tom Lane <[email protected]>
To: [email protected]
Cc: PostgreSQL General <[email protected]>
Subject: Re: Why is this query touching 4gb of buffers?
Date: Fri, 24 Oct 2025 09:01:11 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
hubert depesz lubaczewski <[email protected]> writes:
> On Fri, Oct 24, 2025 at 08:54:06AM -0400, Tom Lane wrote:
>> The first execution probably had to set hint bits on a whole lot
>> of recently-deleted rows.
> But why it doesn't happen/help on secondary?
IIRC, secondaries aren't authorized to update hint bits for
themselves, they have to wait for the primary to do it and then
propagate the new data. There might also be some question of
what the oldest open transaction is ...
regards, tom lane
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 <[email protected]>)
id 1vCHPz-00BZNK-FI
for [email protected]; Fri, 24 Oct 2025 13:01:18 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
by malur.postgresql.org with esmtp (Exim 4.94.2)
(envelope-from <[email protected]>)
id 1vCHPy-00GTUC-5N
for [email protected]; Fri, 24 Oct 2025 13:01: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 <[email protected]>)
id 1vCHPx-00GTU4-RP
for [email protected]; Fri, 24 Oct 2025 13:01:16 +0000
Received: from sss.pgh.pa.us ([68.162.161.243])
by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
(Exim 4.96)
(envelope-from <[email protected]>)
id 1vCHPu-003zl9-1r
for [email protected];
Fri, 24 Oct 2025 13:01:16 +0000
Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 59OD1BRM1755688;
Fri, 24 Oct 2025 09:01:11 -0400
From: Tom Lane <[email protected]>
To: [email protected]
cc: PostgreSQL General <[email protected]>
Subject: Re: Why is this query touching 4gb of buffers?
In-reply-to: <[email protected]>
References: <[email protected]> <[email protected]> <[email protected]> <[email protected]>
Comments: In-reply-to hubert depesz lubaczewski <[email protected]>
message dated "Fri, 24 Oct 2025 14:56:12 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[email protected]>
Date: Fri, 24 Oct 2025 09:01:11 -0400
Message-ID: <[email protected]>
List-Id: <pgsql-general.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/;
List-Subscribe: <https://lists.postgresql.org/manage/;
List-Post: <mailto:[email protected]>
List-Owner: <mailto:[email protected]>
List-Archive: <https://www.postgresql.org/list/pgsql-general;
Archived-At: <https://www.postgresql.org/message-id/1755687.1761310871%40sss.pgh.pa.us;
Precedence: bulk
hubert depesz lubaczewski <[email protected]> writes:
> On Fri, Oct 24, 2025 at 08:54:06AM -0400, Tom Lane wrote:
>> The first execution probably had to set hint bits on a whole lot
>> of recently-deleted rows.
> But why it doesn't happen/help on secondary?
IIRC, secondaries aren't authorized to update hint bits for
themselves, they have to wait for the primary to do it and then
propagate the new data. There might also be some question of
what the oldest open transaction is ...
regards, tom lane
view thread (5+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Why is this query touching 4gb of buffers?
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox