Re: Query regarding pg_prewarm extension - Mailing list pgsql-hackers

From David Rowley
Subject Re: Query regarding pg_prewarm extension
Date
Msg-id CAApHDvpjrj7N=UagoauxkY7J_cLyzzjA6s0tHHKWsPr+KPdfmA@mail.gmail.com
Whole thread Raw
In response to Query regarding pg_prewarm extension  (Ayush Vatsa <ayushvatsa1810@gmail.com>)
Responses Re: Query regarding pg_prewarm extension
List pgsql-hackers
On Sun, 29 Dec 2024 at 14:00, Bruce Momjian <bruce@momjian.us> wrote:
> It feels like we should document what the block range is used for, so
> attached is a doc patch to do that.

-   means prewarm through the last block in the relation).  The return value
-   is the number of blocks prewarmed.
+   means prewarm through the last block in the relation).  The block
+   range allows a single relation to be loaded in parallel using multiple
+   concurent function calls.  The return value is the number of blocks
+   prewarmed.

hmm, do we really need to highlight one specific usage for the range
like this? I think mentioning this could just confuse readers as it
makes it sound like using a range is going to magically run something
in parallel. I was confused to what you were talking about until I
read what Jeremy had written in his email.

Another equally legitimate use case would be if the user only wanted
to prewarm a subset of the relation... Actually, I'd imagine that's
probably more common than someone trying to speed this up by kicking
off multiple queries each with their own range. I imagine there's less
need to use the range to speed this up now that we have read steams
and likely there will be even less need when AIO is in.

I think the current wording is ok as it is. But if I'm outvoted,
"concurent" needs another 'r'.

David



pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: Add the ability to limit the amount of memory that can be allocated to backends.
Next
From: Heikki Linnakangas
Date:
Subject: table_tuple_lock's snapshot argument