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 1tkA9I-000nd4-Kd for pgsql-general@arkaria.postgresql.org; Mon, 17 Feb 2025 23:03:36 +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 1tkA9G-004VSX-MS for pgsql-general@arkaria.postgresql.org; Mon, 17 Feb 2025 23:03:34 +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 1tkA9G-004VSP-BA for pgsql-general@lists.postgresql.org; Mon, 17 Feb 2025 23:03:34 +0000 Received: from mail-oa1-x34.google.com ([2001:4860:4864:20::34]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tkA9E-001RWE-0H for pgsql-general@postgresql.org; Mon, 17 Feb 2025 23:03:34 +0000 Received: by mail-oa1-x34.google.com with SMTP id 586e51a60fabf-2bcf9d9b60aso38758fac.3 for ; Mon, 17 Feb 2025 15:03:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1739833410; x=1740438210; darn=postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=yv+KtFFxv+tTnsPsTSVnJ+Zm5SswmDuO0Ba4/CZx8DI=; b=GhyGqzS0osycr7af85OOPF0Js5WtDU8OTQLbU4XSViUPlnnDDN4rZdktBwVXGZ1dV8 pkuHkLr4N7CyKF2i9TzcD8h40BabiAhpdNdoNoXWyrphRdApcvgmLCXmjvS5EFaaF/+k sRJ6foqbsvyg99ZsMskzR++EGpFehD67ETOtV985UUIIBmXfMWX0Vpj0NAtgfsKO3J0y WPJApNtzMXTLZox2S4ResTUK9XWA2WYo9C8g7ZB6TgYEq4B4IioMP8AOp4OuCzxKLOiT 3NaNJQSgrGvouGaHjIm4RXYUJr4yovgWnnOQeMs+ZEo8t8GaOndMwzgw6kgyDtESjnCT CrKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739833410; x=1740438210; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=yv+KtFFxv+tTnsPsTSVnJ+Zm5SswmDuO0Ba4/CZx8DI=; b=iDOUuT0s4VN7oCGxfTHRaYF1KmmR7KfgJD8DnSwOkNB/+IYGvOBiOtvSqQUYlGUNVY JFsT2idSZQc4ICG5nr9AZKV6h+mJQkc/DyETQ2csA8KFsbtf5sfcRREAew51qiLPIjVj 9swsCYlLPNYEaDXMeJvB9k+9ceFCcZIXv5WKgnlGMzoMYI/2BqBGpfshi+j/bCKSSriC 6QxQzVYuHu3ueS1L6FLPskuSmxSupfCGKNRy1vmLiPk4a7hljW6Nsx1UpIlBa06KKeuf NQKcTUNTd7NChoufAQRJq7SAwXoFHuzl1nsnEpNWrF8xg6st5Rqw9L5fMbB4bhXnEsId 4ATg== X-Gm-Message-State: AOJu0Yz4b9b+IEDLDkpu5cU5iYIWBEyUfsfgAbFz/yRAfgtJ19oEOEpK UcckftrRZq6qRuq2R5iU4UTnnbezGEjOn5od4quv81dZ3Vm5Wvwvu6Z8AIB7QZOMXwC5JOdXhFv 0ZD9dT/cm5+4GW8wfF/lpJEyWHn8htA== X-Gm-Gg: ASbGncu0aZDFU9bf7Kxzpqj1KmBCwzIwdBvFPZ2BMRKafaLyyRYHiaswFp4/VPXJd2r JqgQkryIueog+TWRP8i3r/xl/eN+qv995pJJDguUaB2DeSyeWLxYUC0p8YSW5axRyHI9FL0PFZQ == X-Google-Smtp-Source: AGHT+IGBQqZcJiS5A5UI0XMrArJDzInhuViMeRvMQlswjA2T6M8ikhJZNyUwV93ygOv7Ei3mfveC2vWFvqDLmPODGMs= X-Received: by 2002:a05:6871:5cc:b0:296:df26:8a6e with SMTP id 586e51a60fabf-2bc99dcf766mr7032243fac.35.1739833409776; Mon, 17 Feb 2025 15:03:29 -0800 (PST) MIME-Version: 1.0 References: <931647.1739828197@sss.pgh.pa.us> <933145.1739829070@sss.pgh.pa.us> In-Reply-To: <933145.1739829070@sss.pgh.pa.us> From: Ron Johnson Date: Mon, 17 Feb 2025 18:03:18 -0500 X-Gm-Features: AWEUYZmHqMT9Elok6N6kUHqf0WGxG2m7qyxYM_7r1CFkjZRdC9FY2GrL6PnQlB4 Message-ID: Subject: Re: Loading the latest N rows into the cache seems way too fast. To: pgsql-general Content-Type: multipart/alternative; boundary="0000000000005bb4bf062e5e88ad" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000005bb4bf062e5e88ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 17, 2025 at 4:51=E2=80=AFPM Tom Lane wrote: > Ron Johnson writes: > > On Mon, Feb 17, 2025 at 4:36=E2=80=AFPM Tom Lane wr= ote: > >> It's not pulling in the TOAST storage where the bytea column lives. > >> (pg_prewarm wouldn't have either, without special pushups.) > > > Puzzling, since I ran "PERFORM *". What if I explicitly mentioned the > > bytea column's name? > > You'd have to do something that actually used the column's value, > perhaps "md5(byteacol)" or such. (The obvious candidate would be > length(), but I think that is optimized to not fetch or decompress > the whole value.) > That's definitely taking a LOT longer... --=20 Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --0000000000005bb4bf062e5e88ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Feb 17, 2025 at 4:51=E2=80=AFPM T= om Lane <tgl@sss.pgh.pa.us> = wrote:
Ron Johnson <ronljohnsonjr@gmail.com> write= s:
> On Mon, Feb 17, 2025 at 4:36=E2=80=AFPM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> It's not pulling in the TOAST storage where the bytea column l= ives.
>> (pg_prewarm wouldn't have either, without special pushups.)
> Puzzling, since I ran "PERFORM *".=C2=A0 What if I explicitl= y mentioned the
> bytea column's name?

You'd have to do something that actually used the column's value, perhaps "md5(byteacol)" or such.=C2=A0 (The obvious candidate wou= ld be
length(), but I think that is optimized to not fetch or decompress
the whole value.)

<= /div>
That's definitely taking a LOT longer...

= --
Death to <Redacted>, and butter= sauce.
Don't boil me, I'm still alive.
<Redact= ed> lobster!
--0000000000005bb4bf062e5e88ad--