Re: Query regarding pg_prewarm extension

From: Ayush Vatsa <ayushvatsa1810(at)gmail(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Jeremy Schneider <schneider(at)ardentperf(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Query regarding pg_prewarm extension
Date: 2024-12-30 17:24:21
Message-ID: CACX+KaNb9VuaLGt0Up14Y-g6+KbAv9ZESr9VagAEdLKvFYVagQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 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 believe highlighting that particular use case would indeed be helpful,
but not directly through a change in the documentation. Instead, it
could be better conveyed through an example.

When I initially read the documentation, I found it unclear how someone
would practically use the range feature. For instance, how would a user
determine the specific range of pages they need in the buffer cache?
Since PostgreSQL doesn’t store data in a fixed order and the order can
change over time due to operations like vacuum or updates, this could
be confusing. Hence, an example illustrating the use case would be
valuable.

> 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.

To me, using a range of pages to prewarm a relation doesn’t seem like a
common use case. For example, if a user calls prewarm(100, 200),
how would they decide those specific numbers? While it’s possible to
inspect the contents of those pages, as Jeremy noted, users typically
don’t track the location of specific rows for prewarming purposes.

Regards,
Ayush Vatsa
AWS Aurora

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Shayon Mukherjee 2024-12-30 17:33:02 Re: Proposal to Enable/Disable Index using ALTER INDEX (with patch)
Previous Message vignesh C 2024-12-30 17:01:20 Re: Memory leak in pg_logical_slot_{get,peek}_changes