2005-03-12 15:36:24 +00:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* pg_buffercache_pages.c
|
|
|
|
* display some contents of the buffer cache
|
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* contrib/pg_buffercache/pg_buffercache_pages.c
|
2005-03-12 15:36:24 +00:00
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#include "postgres.h"
|
2006-10-22 17:49:21 +00:00
|
|
|
|
2012-08-30 16:15:44 -04:00
|
|
|
#include "access/htup_details.h"
|
2025-04-08 02:16:51 -04:00
|
|
|
#include "access/relation.h"
|
2005-03-12 15:36:24 +00:00
|
|
|
#include "catalog/pg_type.h"
|
2006-10-22 17:49:21 +00:00
|
|
|
#include "funcapi.h"
|
Add pg_buffercache_numa view with NUMA node info
Introduces a new view pg_buffercache_numa, showing NUMA memory nodes
for individual buffers. For each buffer the view returns an entry for
each memory page, with the associated NUMA node.
The database blocks and OS memory pages may have different size - the
default block size is 8KB, while the memory page is 4K (on x86). But
other combinations are possible, depending on configure parameters,
platform, etc. This means buffers may overlap with multiple memory
pages, each associated with a different NUMA node.
To determine the NUMA node for a buffer, we first need to touch the
memory pages using pg_numa_touch_mem_if_required, otherwise we might get
status -2 (ENOENT = The page is not present), indicating the page is
either unmapped or unallocated.
The view may be relatively expensive, especially when accessed for the
first time in a backend, as it touches all memory pages to get reliable
information about the NUMA node. This may also force allocation of the
shared memory.
Author: Jakub Wartak <jakub.wartak@enterprisedb.com>
Reviewed-by: Andres Freund <andres@anarazel.de>
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Reviewed-by: Tomas Vondra <tomas@vondra.me>
Discussion: https://postgr.es/m/CAKZiRmxh6KWo0aqRqvmcoaX2jUxZYb4kGp3N%3Dq1w%2BDiH-696Xw%40mail.gmail.com
2025-04-07 22:56:57 +02:00
|
|
|
#include "port/pg_numa.h"
|
2005-03-12 15:36:24 +00:00
|
|
|
#include "storage/buf_internals.h"
|
|
|
|
#include "storage/bufmgr.h"
|
2025-04-08 02:16:51 -04:00
|
|
|
#include "utils/rel.h"
|
2005-03-12 15:36:24 +00:00
|
|
|
|
|
|
|
|
2014-08-22 00:28:37 +02:00
|
|
|
#define NUM_BUFFERCACHE_PAGES_MIN_ELEM 8
|
|
|
|
#define NUM_BUFFERCACHE_PAGES_ELEM 9
|
2022-10-13 09:55:46 -07:00
|
|
|
#define NUM_BUFFERCACHE_SUMMARY_ELEM 5
|
2023-04-07 14:25:45 -04:00
|
|
|
#define NUM_BUFFERCACHE_USAGE_COUNTS_ELEM 4
|
2025-04-08 02:16:51 -04:00
|
|
|
#define NUM_BUFFERCACHE_EVICT_ELEM 2
|
|
|
|
#define NUM_BUFFERCACHE_EVICT_RELATION_ELEM 3
|
|
|
|
#define NUM_BUFFERCACHE_EVICT_ALL_ELEM 3
|
2005-03-12 15:36:24 +00:00
|
|
|
|
Add pg_buffercache_numa view with NUMA node info
Introduces a new view pg_buffercache_numa, showing NUMA memory nodes
for individual buffers. For each buffer the view returns an entry for
each memory page, with the associated NUMA node.
The database blocks and OS memory pages may have different size - the
default block size is 8KB, while the memory page is 4K (on x86). But
other combinations are possible, depending on configure parameters,
platform, etc. This means buffers may overlap with multiple memory
pages, each associated with a different NUMA node.
To determine the NUMA node for a buffer, we first need to touch the
memory pages using pg_numa_touch_mem_if_required, otherwise we might get
status -2 (ENOENT = The page is not present), indicating the page is
either unmapped or unallocated.
The view may be relatively expensive, especially when accessed for the
first time in a backend, as it touches all memory pages to get reliable
information about the NUMA node. This may also force allocation of the
shared memory.
Author: Jakub Wartak <jakub.wartak@enterprisedb.com>
Reviewed-by: Andres Freund <andres@anarazel.de>
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Reviewed-by: Tomas Vondra <tomas@vondra.me>
Discussion: https://postgr.es/m/CAKZiRmxh6KWo0aqRqvmcoaX2jUxZYb4kGp3N%3Dq1w%2BDiH-696Xw%40mail.gmail.com
2025-04-07 22:56:57 +02:00
|
|
|
#define NUM_BUFFERCACHE_NUMA_ELEM 3
|
|
|
|
|
2025-03-26 11:11:02 -04:00
|
|
|
PG_MODULE_MAGIC_EXT(
|
|
|
|
.name = "pg_buffercache",
|
|
|
|
.version = PG_VERSION
|
|
|
|
);
|
2006-05-30 22:12:16 +00:00
|
|
|
|
2005-03-12 15:36:24 +00:00
|
|
|
/*
|
|
|
|
* Record structure holding the to be exposed cache data.
|
|
|
|
*/
|
|
|
|
typedef struct
|
|
|
|
{
|
|
|
|
uint32 bufferid;
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 11:39:09 -04:00
|
|
|
RelFileNumber relfilenumber;
|
2005-03-12 15:36:24 +00:00
|
|
|
Oid reltablespace;
|
|
|
|
Oid reldatabase;
|
2008-08-14 12:56:41 +00:00
|
|
|
ForkNumber forknum;
|
2005-03-12 15:36:24 +00:00
|
|
|
BlockNumber blocknum;
|
|
|
|
bool isvalid;
|
|
|
|
bool isdirty;
|
2007-04-07 16:09:14 +00:00
|
|
|
uint16 usagecount;
|
2015-05-23 21:35:49 -04:00
|
|
|
|
2014-08-22 00:28:37 +02:00
|
|
|
/*
|
|
|
|
* An int32 is sufficiently large, as MAX_BACKENDS prevents a buffer from
|
|
|
|
* being pinned by too many backends and each backend will only pin once
|
2014-08-30 14:03:21 +02:00
|
|
|
* because of bufmgr.c's PrivateRefCount infrastructure.
|
2014-08-22 00:28:37 +02:00
|
|
|
*/
|
|
|
|
int32 pinning_backends;
|
2005-03-12 15:36:24 +00:00
|
|
|
} BufferCachePagesRec;
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Function context for data persisting over repeated calls.
|
|
|
|
*/
|
|
|
|
typedef struct
|
|
|
|
{
|
2006-10-22 17:49:21 +00:00
|
|
|
TupleDesc tupdesc;
|
2005-03-12 15:36:24 +00:00
|
|
|
BufferCachePagesRec *record;
|
|
|
|
} BufferCachePagesContext;
|
|
|
|
|
Add pg_buffercache_numa view with NUMA node info
Introduces a new view pg_buffercache_numa, showing NUMA memory nodes
for individual buffers. For each buffer the view returns an entry for
each memory page, with the associated NUMA node.
The database blocks and OS memory pages may have different size - the
default block size is 8KB, while the memory page is 4K (on x86). But
other combinations are possible, depending on configure parameters,
platform, etc. This means buffers may overlap with multiple memory
pages, each associated with a different NUMA node.
To determine the NUMA node for a buffer, we first need to touch the
memory pages using pg_numa_touch_mem_if_required, otherwise we might get
status -2 (ENOENT = The page is not present), indicating the page is
either unmapped or unallocated.
The view may be relatively expensive, especially when accessed for the
first time in a backend, as it touches all memory pages to get reliable
information about the NUMA node. This may also force allocation of the
shared memory.
Author: Jakub Wartak <jakub.wartak@enterprisedb.com>
Reviewed-by: Andres Freund <andres@anarazel.de>
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Reviewed-by: Tomas Vondra <tomas@vondra.me>
Discussion: https://postgr.es/m/CAKZiRmxh6KWo0aqRqvmcoaX2jUxZYb4kGp3N%3Dq1w%2BDiH-696Xw%40mail.gmail.com
2025-04-07 22:56:57 +02:00
|
|
|
/*
|
|
|
|
* Record structure holding the to be exposed cache data.
|
|
|
|
*/
|
|
|
|
typedef struct
|
|
|
|
{
|
|
|
|
uint32 bufferid;
|
2025-04-08 11:52:02 +02:00
|
|
|
int64 page_num;
|
Add pg_buffercache_numa view with NUMA node info
Introduces a new view pg_buffercache_numa, showing NUMA memory nodes
for individual buffers. For each buffer the view returns an entry for
each memory page, with the associated NUMA node.
The database blocks and OS memory pages may have different size - the
default block size is 8KB, while the memory page is 4K (on x86). But
other combinations are possible, depending on configure parameters,
platform, etc. This means buffers may overlap with multiple memory
pages, each associated with a different NUMA node.
To determine the NUMA node for a buffer, we first need to touch the
memory pages using pg_numa_touch_mem_if_required, otherwise we might get
status -2 (ENOENT = The page is not present), indicating the page is
either unmapped or unallocated.
The view may be relatively expensive, especially when accessed for the
first time in a backend, as it touches all memory pages to get reliable
information about the NUMA node. This may also force allocation of the
shared memory.
Author: Jakub Wartak <jakub.wartak@enterprisedb.com>
Reviewed-by: Andres Freund <andres@anarazel.de>
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Reviewed-by: Tomas Vondra <tomas@vondra.me>
Discussion: https://postgr.es/m/CAKZiRmxh6KWo0aqRqvmcoaX2jUxZYb4kGp3N%3Dq1w%2BDiH-696Xw%40mail.gmail.com
2025-04-07 22:56:57 +02:00
|
|
|
int32 numa_node;
|
|
|
|
} BufferCacheNumaRec;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Function context for data persisting over repeated calls.
|
|
|
|
*/
|
|
|
|
typedef struct
|
|
|
|
{
|
|
|
|
TupleDesc tupdesc;
|
|
|
|
int buffers_per_page;
|
|
|
|
int pages_per_buffer;
|
|
|
|
int os_page_size;
|
|
|
|
BufferCacheNumaRec *record;
|
|
|
|
} BufferCacheNumaContext;
|
|
|
|
|
2005-03-12 15:36:24 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Function returning data from the shared buffer cache - buffer number,
|
|
|
|
* relation node/tablespace/database/blocknum and dirty indicator.
|
|
|
|
*/
|
|
|
|
PG_FUNCTION_INFO_V1(pg_buffercache_pages);
|
Add pg_buffercache_numa view with NUMA node info
Introduces a new view pg_buffercache_numa, showing NUMA memory nodes
for individual buffers. For each buffer the view returns an entry for
each memory page, with the associated NUMA node.
The database blocks and OS memory pages may have different size - the
default block size is 8KB, while the memory page is 4K (on x86). But
other combinations are possible, depending on configure parameters,
platform, etc. This means buffers may overlap with multiple memory
pages, each associated with a different NUMA node.
To determine the NUMA node for a buffer, we first need to touch the
memory pages using pg_numa_touch_mem_if_required, otherwise we might get
status -2 (ENOENT = The page is not present), indicating the page is
either unmapped or unallocated.
The view may be relatively expensive, especially when accessed for the
first time in a backend, as it touches all memory pages to get reliable
information about the NUMA node. This may also force allocation of the
shared memory.
Author: Jakub Wartak <jakub.wartak@enterprisedb.com>
Reviewed-by: Andres Freund <andres@anarazel.de>
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Reviewed-by: Tomas Vondra <tomas@vondra.me>
Discussion: https://postgr.es/m/CAKZiRmxh6KWo0aqRqvmcoaX2jUxZYb4kGp3N%3Dq1w%2BDiH-696Xw%40mail.gmail.com
2025-04-07 22:56:57 +02:00
|
|
|
PG_FUNCTION_INFO_V1(pg_buffercache_numa_pages);
|
2022-10-13 09:55:46 -07:00
|
|
|
PG_FUNCTION_INFO_V1(pg_buffercache_summary);
|
2023-04-07 14:25:45 -04:00
|
|
|
PG_FUNCTION_INFO_V1(pg_buffercache_usage_counts);
|
2024-04-07 09:13:17 +12:00
|
|
|
PG_FUNCTION_INFO_V1(pg_buffercache_evict);
|
2025-04-08 02:16:51 -04:00
|
|
|
PG_FUNCTION_INFO_V1(pg_buffercache_evict_relation);
|
|
|
|
PG_FUNCTION_INFO_V1(pg_buffercache_evict_all);
|
2006-10-22 17:49:21 +00:00
|
|
|
|
Add pg_buffercache_numa view with NUMA node info
Introduces a new view pg_buffercache_numa, showing NUMA memory nodes
for individual buffers. For each buffer the view returns an entry for
each memory page, with the associated NUMA node.
The database blocks and OS memory pages may have different size - the
default block size is 8KB, while the memory page is 4K (on x86). But
other combinations are possible, depending on configure parameters,
platform, etc. This means buffers may overlap with multiple memory
pages, each associated with a different NUMA node.
To determine the NUMA node for a buffer, we first need to touch the
memory pages using pg_numa_touch_mem_if_required, otherwise we might get
status -2 (ENOENT = The page is not present), indicating the page is
either unmapped or unallocated.
The view may be relatively expensive, especially when accessed for the
first time in a backend, as it touches all memory pages to get reliable
information about the NUMA node. This may also force allocation of the
shared memory.
Author: Jakub Wartak <jakub.wartak@enterprisedb.com>
Reviewed-by: Andres Freund <andres@anarazel.de>
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Reviewed-by: Tomas Vondra <tomas@vondra.me>
Discussion: https://postgr.es/m/CAKZiRmxh6KWo0aqRqvmcoaX2jUxZYb4kGp3N%3Dq1w%2BDiH-696Xw%40mail.gmail.com
2025-04-07 22:56:57 +02:00
|
|
|
|
|
|
|
/* Only need to touch memory once per backend process lifetime */
|
|
|
|
static bool firstNumaTouch = true;
|
|
|
|
|
|
|
|
|
2022-09-28 09:45:27 -04:00
|
|
|
Datum
|
|
|
|
pg_buffercache_pages(PG_FUNCTION_ARGS)
|
2005-03-12 15:36:24 +00:00
|
|
|
{
|
|
|
|
FuncCallContext *funcctx;
|
|
|
|
Datum result;
|
|
|
|
MemoryContext oldcontext;
|
|
|
|
BufferCachePagesContext *fctx; /* User function context. */
|
|
|
|
TupleDesc tupledesc;
|
2014-08-22 00:28:37 +02:00
|
|
|
TupleDesc expected_tupledesc;
|
2005-03-12 15:36:24 +00:00
|
|
|
HeapTuple tuple;
|
|
|
|
|
|
|
|
if (SRF_IS_FIRSTCALL())
|
|
|
|
{
|
2006-07-23 03:07:58 +00:00
|
|
|
int i;
|
2005-03-12 15:36:24 +00:00
|
|
|
|
|
|
|
funcctx = SRF_FIRSTCALL_INIT();
|
|
|
|
|
|
|
|
/* Switch context when allocating stuff to be used in later calls */
|
|
|
|
oldcontext = MemoryContextSwitchTo(funcctx->multi_call_memory_ctx);
|
2005-10-15 02:49:52 +00:00
|
|
|
|
2006-10-22 17:49:21 +00:00
|
|
|
/* Create a user function context for cross-call persistence */
|
|
|
|
fctx = (BufferCachePagesContext *) palloc(sizeof(BufferCachePagesContext));
|
|
|
|
|
2014-08-22 00:28:37 +02:00
|
|
|
/*
|
|
|
|
* To smoothly support upgrades from version 1.0 of this extension
|
2014-08-22 09:25:47 +02:00
|
|
|
* transparently handle the (non-)existence of the pinning_backends
|
2014-08-22 00:28:37 +02:00
|
|
|
* column. We unfortunately have to get the result type for that... -
|
|
|
|
* we can't use the result type determined by the function definition
|
|
|
|
* without potentially crashing when somebody uses the old (or even
|
|
|
|
* wrong) function definition though.
|
|
|
|
*/
|
|
|
|
if (get_call_result_type(fcinfo, NULL, &expected_tupledesc) != TYPEFUNC_COMPOSITE)
|
|
|
|
elog(ERROR, "return type must be a row type");
|
|
|
|
|
|
|
|
if (expected_tupledesc->natts < NUM_BUFFERCACHE_PAGES_MIN_ELEM ||
|
|
|
|
expected_tupledesc->natts > NUM_BUFFERCACHE_PAGES_ELEM)
|
|
|
|
elog(ERROR, "incorrect number of output arguments");
|
|
|
|
|
2006-10-22 17:49:21 +00:00
|
|
|
/* Construct a tuple descriptor for the result rows. */
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-20 15:36:57 -08:00
|
|
|
tupledesc = CreateTemplateTupleDesc(expected_tupledesc->natts);
|
2005-03-12 15:36:24 +00:00
|
|
|
TupleDescInitEntry(tupledesc, (AttrNumber) 1, "bufferid",
|
|
|
|
INT4OID, -1, 0);
|
|
|
|
TupleDescInitEntry(tupledesc, (AttrNumber) 2, "relfilenode",
|
2022-09-28 09:45:27 -04:00
|
|
|
OIDOID, -1, 0);
|
2005-03-12 15:36:24 +00:00
|
|
|
TupleDescInitEntry(tupledesc, (AttrNumber) 3, "reltablespace",
|
|
|
|
OIDOID, -1, 0);
|
|
|
|
TupleDescInitEntry(tupledesc, (AttrNumber) 4, "reldatabase",
|
|
|
|
OIDOID, -1, 0);
|
2008-08-14 12:56:41 +00:00
|
|
|
TupleDescInitEntry(tupledesc, (AttrNumber) 5, "relforknumber",
|
|
|
|
INT2OID, -1, 0);
|
|
|
|
TupleDescInitEntry(tupledesc, (AttrNumber) 6, "relblocknumber",
|
2005-05-31 00:07:47 +00:00
|
|
|
INT8OID, -1, 0);
|
2008-08-14 12:56:41 +00:00
|
|
|
TupleDescInitEntry(tupledesc, (AttrNumber) 7, "isdirty",
|
2005-03-12 15:36:24 +00:00
|
|
|
BOOLOID, -1, 0);
|
2008-08-14 12:56:41 +00:00
|
|
|
TupleDescInitEntry(tupledesc, (AttrNumber) 8, "usage_count",
|
2007-04-07 16:09:14 +00:00
|
|
|
INT2OID, -1, 0);
|
2005-03-12 15:36:24 +00:00
|
|
|
|
2014-08-22 00:28:37 +02:00
|
|
|
if (expected_tupledesc->natts == NUM_BUFFERCACHE_PAGES_ELEM)
|
|
|
|
TupleDescInitEntry(tupledesc, (AttrNumber) 9, "pinning_backends",
|
|
|
|
INT4OID, -1, 0);
|
|
|
|
|
2006-10-22 17:49:21 +00:00
|
|
|
fctx->tupdesc = BlessTupleDesc(tupledesc);
|
2005-03-12 15:36:24 +00:00
|
|
|
|
|
|
|
/* Allocate NBuffers worth of BufferCachePagesRec records. */
|
2016-09-15 09:22:52 -04:00
|
|
|
fctx->record = (BufferCachePagesRec *)
|
|
|
|
MemoryContextAllocHuge(CurrentMemoryContext,
|
|
|
|
sizeof(BufferCachePagesRec) * NBuffers);
|
2005-03-12 15:36:24 +00:00
|
|
|
|
2006-10-22 17:49:21 +00:00
|
|
|
/* Set max calls and remember the user function context. */
|
|
|
|
funcctx->max_calls = NBuffers;
|
|
|
|
funcctx->user_fctx = fctx;
|
2005-03-12 15:36:24 +00:00
|
|
|
|
|
|
|
/* Return to original context when allocating transient memory */
|
|
|
|
MemoryContextSwitchTo(oldcontext);
|
|
|
|
|
2006-07-23 03:07:58 +00:00
|
|
|
/*
|
2015-05-20 16:18:11 +03:00
|
|
|
* Scan through all the buffers, saving the relevant fields in the
|
2006-07-23 03:07:58 +00:00
|
|
|
* fctx->record structure.
|
2016-09-29 13:16:30 +03:00
|
|
|
*
|
|
|
|
* We don't hold the partition locks, so we don't get a consistent
|
|
|
|
* snapshot across all buffers, but we do grab the buffer header
|
|
|
|
* locks, so the information of each buffer is self-consistent.
|
2006-07-23 03:07:58 +00:00
|
|
|
*/
|
Align buffer descriptors to cache line boundaries.
Benchmarks has shown that aligning the buffer descriptor array to
cache lines is important for scalability; especially on bigger,
multi-socket, machines.
Currently the array sometimes already happens to be aligned by
happenstance, depending how large previous shared memory allocations
were. That can lead to wildly varying performance results after minor
configuration changes.
In addition to aligning the start of descriptor array, also force the
size of individual descriptors to be of a common cache line size (64
bytes). That happens to already be the case on 64bit platforms, but
this way we can change the struct BufferDesc more easily.
As the alignment primarily matters in highly concurrent workloads
which probably all are 64bit these days, and the space wastage of
element alignment would be a bit more noticeable on 32bit systems, we
don't force the stride to be cacheline sized on 32bit platforms for
now. If somebody does actual performance testing, we can reevaluate
that decision by changing the definition of BUFFERDESC_PADDED_SIZE.
Discussion: 20140202151319.GD32123@awork2.anarazel.de
Per discussion with Bruce Momjan, Tom Lane, Robert Haas, and Peter
Geoghegan.
2015-01-29 17:49:03 +01:00
|
|
|
for (i = 0; i < NBuffers; i++)
|
2005-03-12 15:36:24 +00:00
|
|
|
{
|
Allow Pin/UnpinBuffer to operate in a lockfree manner.
Pinning/Unpinning a buffer is a very frequent operation; especially in
read-mostly cache resident workloads. Benchmarking shows that in various
scenarios the spinlock protecting a buffer header's state becomes a
significant bottleneck. The problem can be reproduced with pgbench -S on
larger machines, but can be considerably worse for queries which touch
the same buffers over and over at a high frequency (e.g. nested loops
over a small inner table).
To allow atomic operations to be used, cram BufferDesc's flags,
usage_count, buf_hdr_lock, refcount into a single 32bit atomic variable;
that allows to manipulate them together using 32bit compare-and-swap
operations. This requires reducing MAX_BACKENDS to 2^18-1 (which could
be lifted by using a 64bit field, but it's not a realistic configuration
atm).
As not all operations can easily implemented in a lockfree manner,
implement the previous buf_hdr_lock via a flag bit in the atomic
variable. That way we can continue to lock the header in places where
it's needed, but can get away without acquiring it in the more frequent
hot-paths. There's some additional operations which can be done without
the lock, but aren't in this patch; but the most important places are
covered.
As bufmgr.c now essentially re-implements spinlocks, abstract the delay
logic from s_lock.c into something more generic. It now has already two
users, and more are coming up; there's a follupw patch for lwlock.c at
least.
This patch is based on a proof-of-concept written by me, which Alexander
Korotkov made into a fully working patch; the committed version is again
revised by me. Benchmarking and testing has, amongst others, been
provided by Dilip Kumar, Alexander Korotkov, Robert Haas.
On a large x86 system improvements for readonly pgbench, with a high
client count, of a factor of 8 have been observed.
Author: Alexander Korotkov and Andres Freund
Discussion: 2400449.GjM57CE0Yg@dinodell
2016-04-10 20:12:32 -07:00
|
|
|
BufferDesc *bufHdr;
|
|
|
|
uint32 buf_state;
|
Align buffer descriptors to cache line boundaries.
Benchmarks has shown that aligning the buffer descriptor array to
cache lines is important for scalability; especially on bigger,
multi-socket, machines.
Currently the array sometimes already happens to be aligned by
happenstance, depending how large previous shared memory allocations
were. That can lead to wildly varying performance results after minor
configuration changes.
In addition to aligning the start of descriptor array, also force the
size of individual descriptors to be of a common cache line size (64
bytes). That happens to already be the case on 64bit platforms, but
this way we can change the struct BufferDesc more easily.
As the alignment primarily matters in highly concurrent workloads
which probably all are 64bit these days, and the space wastage of
element alignment would be a bit more noticeable on 32bit systems, we
don't force the stride to be cacheline sized on 32bit platforms for
now. If somebody does actual performance testing, we can reevaluate
that decision by changing the definition of BUFFERDESC_PADDED_SIZE.
Discussion: 20140202151319.GD32123@awork2.anarazel.de
Per discussion with Bruce Momjan, Tom Lane, Robert Haas, and Peter
Geoghegan.
2015-01-29 17:49:03 +01:00
|
|
|
|
|
|
|
bufHdr = GetBufferDescriptor(i);
|
2005-03-12 15:36:24 +00:00
|
|
|
/* Lock each buffer header before inspecting. */
|
Allow Pin/UnpinBuffer to operate in a lockfree manner.
Pinning/Unpinning a buffer is a very frequent operation; especially in
read-mostly cache resident workloads. Benchmarking shows that in various
scenarios the spinlock protecting a buffer header's state becomes a
significant bottleneck. The problem can be reproduced with pgbench -S on
larger machines, but can be considerably worse for queries which touch
the same buffers over and over at a high frequency (e.g. nested loops
over a small inner table).
To allow atomic operations to be used, cram BufferDesc's flags,
usage_count, buf_hdr_lock, refcount into a single 32bit atomic variable;
that allows to manipulate them together using 32bit compare-and-swap
operations. This requires reducing MAX_BACKENDS to 2^18-1 (which could
be lifted by using a 64bit field, but it's not a realistic configuration
atm).
As not all operations can easily implemented in a lockfree manner,
implement the previous buf_hdr_lock via a flag bit in the atomic
variable. That way we can continue to lock the header in places where
it's needed, but can get away without acquiring it in the more frequent
hot-paths. There's some additional operations which can be done without
the lock, but aren't in this patch; but the most important places are
covered.
As bufmgr.c now essentially re-implements spinlocks, abstract the delay
logic from s_lock.c into something more generic. It now has already two
users, and more are coming up; there's a follupw patch for lwlock.c at
least.
This patch is based on a proof-of-concept written by me, which Alexander
Korotkov made into a fully working patch; the committed version is again
revised by me. Benchmarking and testing has, amongst others, been
provided by Dilip Kumar, Alexander Korotkov, Robert Haas.
On a large x86 system improvements for readonly pgbench, with a high
client count, of a factor of 8 have been observed.
Author: Alexander Korotkov and Andres Freund
Discussion: 2400449.GjM57CE0Yg@dinodell
2016-04-10 20:12:32 -07:00
|
|
|
buf_state = LockBufHdr(bufHdr);
|
2005-03-12 15:36:24 +00:00
|
|
|
|
|
|
|
fctx->record[i].bufferid = BufferDescriptorGetBuffer(bufHdr);
|
2022-08-24 15:50:48 -04:00
|
|
|
fctx->record[i].relfilenumber = BufTagGetRelNumber(&bufHdr->tag);
|
|
|
|
fctx->record[i].reltablespace = bufHdr->tag.spcOid;
|
|
|
|
fctx->record[i].reldatabase = bufHdr->tag.dbOid;
|
|
|
|
fctx->record[i].forknum = BufTagGetForkNum(&bufHdr->tag);
|
2005-03-12 15:36:24 +00:00
|
|
|
fctx->record[i].blocknum = bufHdr->tag.blockNum;
|
Allow Pin/UnpinBuffer to operate in a lockfree manner.
Pinning/Unpinning a buffer is a very frequent operation; especially in
read-mostly cache resident workloads. Benchmarking shows that in various
scenarios the spinlock protecting a buffer header's state becomes a
significant bottleneck. The problem can be reproduced with pgbench -S on
larger machines, but can be considerably worse for queries which touch
the same buffers over and over at a high frequency (e.g. nested loops
over a small inner table).
To allow atomic operations to be used, cram BufferDesc's flags,
usage_count, buf_hdr_lock, refcount into a single 32bit atomic variable;
that allows to manipulate them together using 32bit compare-and-swap
operations. This requires reducing MAX_BACKENDS to 2^18-1 (which could
be lifted by using a 64bit field, but it's not a realistic configuration
atm).
As not all operations can easily implemented in a lockfree manner,
implement the previous buf_hdr_lock via a flag bit in the atomic
variable. That way we can continue to lock the header in places where
it's needed, but can get away without acquiring it in the more frequent
hot-paths. There's some additional operations which can be done without
the lock, but aren't in this patch; but the most important places are
covered.
As bufmgr.c now essentially re-implements spinlocks, abstract the delay
logic from s_lock.c into something more generic. It now has already two
users, and more are coming up; there's a follupw patch for lwlock.c at
least.
This patch is based on a proof-of-concept written by me, which Alexander
Korotkov made into a fully working patch; the committed version is again
revised by me. Benchmarking and testing has, amongst others, been
provided by Dilip Kumar, Alexander Korotkov, Robert Haas.
On a large x86 system improvements for readonly pgbench, with a high
client count, of a factor of 8 have been observed.
Author: Alexander Korotkov and Andres Freund
Discussion: 2400449.GjM57CE0Yg@dinodell
2016-04-10 20:12:32 -07:00
|
|
|
fctx->record[i].usagecount = BUF_STATE_GET_USAGECOUNT(buf_state);
|
|
|
|
fctx->record[i].pinning_backends = BUF_STATE_GET_REFCOUNT(buf_state);
|
2005-03-12 15:36:24 +00:00
|
|
|
|
Allow Pin/UnpinBuffer to operate in a lockfree manner.
Pinning/Unpinning a buffer is a very frequent operation; especially in
read-mostly cache resident workloads. Benchmarking shows that in various
scenarios the spinlock protecting a buffer header's state becomes a
significant bottleneck. The problem can be reproduced with pgbench -S on
larger machines, but can be considerably worse for queries which touch
the same buffers over and over at a high frequency (e.g. nested loops
over a small inner table).
To allow atomic operations to be used, cram BufferDesc's flags,
usage_count, buf_hdr_lock, refcount into a single 32bit atomic variable;
that allows to manipulate them together using 32bit compare-and-swap
operations. This requires reducing MAX_BACKENDS to 2^18-1 (which could
be lifted by using a 64bit field, but it's not a realistic configuration
atm).
As not all operations can easily implemented in a lockfree manner,
implement the previous buf_hdr_lock via a flag bit in the atomic
variable. That way we can continue to lock the header in places where
it's needed, but can get away without acquiring it in the more frequent
hot-paths. There's some additional operations which can be done without
the lock, but aren't in this patch; but the most important places are
covered.
As bufmgr.c now essentially re-implements spinlocks, abstract the delay
logic from s_lock.c into something more generic. It now has already two
users, and more are coming up; there's a follupw patch for lwlock.c at
least.
This patch is based on a proof-of-concept written by me, which Alexander
Korotkov made into a fully working patch; the committed version is again
revised by me. Benchmarking and testing has, amongst others, been
provided by Dilip Kumar, Alexander Korotkov, Robert Haas.
On a large x86 system improvements for readonly pgbench, with a high
client count, of a factor of 8 have been observed.
Author: Alexander Korotkov and Andres Freund
Discussion: 2400449.GjM57CE0Yg@dinodell
2016-04-10 20:12:32 -07:00
|
|
|
if (buf_state & BM_DIRTY)
|
2005-03-12 15:36:24 +00:00
|
|
|
fctx->record[i].isdirty = true;
|
|
|
|
else
|
|
|
|
fctx->record[i].isdirty = false;
|
|
|
|
|
|
|
|
/* Note if the buffer is valid, and has storage created */
|
Allow Pin/UnpinBuffer to operate in a lockfree manner.
Pinning/Unpinning a buffer is a very frequent operation; especially in
read-mostly cache resident workloads. Benchmarking shows that in various
scenarios the spinlock protecting a buffer header's state becomes a
significant bottleneck. The problem can be reproduced with pgbench -S on
larger machines, but can be considerably worse for queries which touch
the same buffers over and over at a high frequency (e.g. nested loops
over a small inner table).
To allow atomic operations to be used, cram BufferDesc's flags,
usage_count, buf_hdr_lock, refcount into a single 32bit atomic variable;
that allows to manipulate them together using 32bit compare-and-swap
operations. This requires reducing MAX_BACKENDS to 2^18-1 (which could
be lifted by using a 64bit field, but it's not a realistic configuration
atm).
As not all operations can easily implemented in a lockfree manner,
implement the previous buf_hdr_lock via a flag bit in the atomic
variable. That way we can continue to lock the header in places where
it's needed, but can get away without acquiring it in the more frequent
hot-paths. There's some additional operations which can be done without
the lock, but aren't in this patch; but the most important places are
covered.
As bufmgr.c now essentially re-implements spinlocks, abstract the delay
logic from s_lock.c into something more generic. It now has already two
users, and more are coming up; there's a follupw patch for lwlock.c at
least.
This patch is based on a proof-of-concept written by me, which Alexander
Korotkov made into a fully working patch; the committed version is again
revised by me. Benchmarking and testing has, amongst others, been
provided by Dilip Kumar, Alexander Korotkov, Robert Haas.
On a large x86 system improvements for readonly pgbench, with a high
client count, of a factor of 8 have been observed.
Author: Alexander Korotkov and Andres Freund
Discussion: 2400449.GjM57CE0Yg@dinodell
2016-04-10 20:12:32 -07:00
|
|
|
if ((buf_state & BM_VALID) && (buf_state & BM_TAG_VALID))
|
2005-03-12 15:36:24 +00:00
|
|
|
fctx->record[i].isvalid = true;
|
|
|
|
else
|
|
|
|
fctx->record[i].isvalid = false;
|
|
|
|
|
Allow Pin/UnpinBuffer to operate in a lockfree manner.
Pinning/Unpinning a buffer is a very frequent operation; especially in
read-mostly cache resident workloads. Benchmarking shows that in various
scenarios the spinlock protecting a buffer header's state becomes a
significant bottleneck. The problem can be reproduced with pgbench -S on
larger machines, but can be considerably worse for queries which touch
the same buffers over and over at a high frequency (e.g. nested loops
over a small inner table).
To allow atomic operations to be used, cram BufferDesc's flags,
usage_count, buf_hdr_lock, refcount into a single 32bit atomic variable;
that allows to manipulate them together using 32bit compare-and-swap
operations. This requires reducing MAX_BACKENDS to 2^18-1 (which could
be lifted by using a 64bit field, but it's not a realistic configuration
atm).
As not all operations can easily implemented in a lockfree manner,
implement the previous buf_hdr_lock via a flag bit in the atomic
variable. That way we can continue to lock the header in places where
it's needed, but can get away without acquiring it in the more frequent
hot-paths. There's some additional operations which can be done without
the lock, but aren't in this patch; but the most important places are
covered.
As bufmgr.c now essentially re-implements spinlocks, abstract the delay
logic from s_lock.c into something more generic. It now has already two
users, and more are coming up; there's a follupw patch for lwlock.c at
least.
This patch is based on a proof-of-concept written by me, which Alexander
Korotkov made into a fully working patch; the committed version is again
revised by me. Benchmarking and testing has, amongst others, been
provided by Dilip Kumar, Alexander Korotkov, Robert Haas.
On a large x86 system improvements for readonly pgbench, with a high
client count, of a factor of 8 have been observed.
Author: Alexander Korotkov and Andres Freund
Discussion: 2400449.GjM57CE0Yg@dinodell
2016-04-10 20:12:32 -07:00
|
|
|
UnlockBufHdr(bufHdr, buf_state);
|
2005-03-12 15:36:24 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
funcctx = SRF_PERCALL_SETUP();
|
2005-10-15 02:49:52 +00:00
|
|
|
|
2005-03-12 15:36:24 +00:00
|
|
|
/* Get the saved state */
|
|
|
|
fctx = funcctx->user_fctx;
|
|
|
|
|
|
|
|
if (funcctx->call_cntr < funcctx->max_calls)
|
|
|
|
{
|
|
|
|
uint32 i = funcctx->call_cntr;
|
2006-10-22 17:49:21 +00:00
|
|
|
Datum values[NUM_BUFFERCACHE_PAGES_ELEM];
|
|
|
|
bool nulls[NUM_BUFFERCACHE_PAGES_ELEM];
|
2005-10-15 02:49:52 +00:00
|
|
|
|
2006-10-22 17:49:21 +00:00
|
|
|
values[0] = Int32GetDatum(fctx->record[i].bufferid);
|
|
|
|
nulls[0] = false;
|
2005-03-12 15:36:24 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Set all fields except the bufferid to null if the buffer is unused
|
|
|
|
* or not valid.
|
|
|
|
*/
|
|
|
|
if (fctx->record[i].blocknum == InvalidBlockNumber ||
|
|
|
|
fctx->record[i].isvalid == false)
|
|
|
|
{
|
2006-10-22 17:49:21 +00:00
|
|
|
nulls[1] = true;
|
|
|
|
nulls[2] = true;
|
|
|
|
nulls[3] = true;
|
|
|
|
nulls[4] = true;
|
|
|
|
nulls[5] = true;
|
2007-04-07 16:09:14 +00:00
|
|
|
nulls[6] = true;
|
2008-08-14 12:56:41 +00:00
|
|
|
nulls[7] = true;
|
2014-08-22 00:28:37 +02:00
|
|
|
/* unused for v1.0 callers, but the array is always long enough */
|
|
|
|
nulls[8] = true;
|
2005-03-12 15:36:24 +00:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2022-09-28 09:45:27 -04:00
|
|
|
values[1] = ObjectIdGetDatum(fctx->record[i].relfilenumber);
|
2006-10-22 17:49:21 +00:00
|
|
|
nulls[1] = false;
|
|
|
|
values[2] = ObjectIdGetDatum(fctx->record[i].reltablespace);
|
|
|
|
nulls[2] = false;
|
|
|
|
values[3] = ObjectIdGetDatum(fctx->record[i].reldatabase);
|
|
|
|
nulls[3] = false;
|
2008-08-14 12:56:41 +00:00
|
|
|
values[4] = ObjectIdGetDatum(fctx->record[i].forknum);
|
2006-10-22 17:49:21 +00:00
|
|
|
nulls[4] = false;
|
2008-08-14 12:56:41 +00:00
|
|
|
values[5] = Int64GetDatum((int64) fctx->record[i].blocknum);
|
2006-10-22 17:49:21 +00:00
|
|
|
nulls[5] = false;
|
2008-08-14 12:56:41 +00:00
|
|
|
values[6] = BoolGetDatum(fctx->record[i].isdirty);
|
2007-04-07 16:09:14 +00:00
|
|
|
nulls[6] = false;
|
2008-08-14 12:56:41 +00:00
|
|
|
values[7] = Int16GetDatum(fctx->record[i].usagecount);
|
|
|
|
nulls[7] = false;
|
2014-08-22 00:28:37 +02:00
|
|
|
/* unused for v1.0 callers, but the array is always long enough */
|
|
|
|
values[8] = Int32GetDatum(fctx->record[i].pinning_backends);
|
|
|
|
nulls[8] = false;
|
2005-03-12 15:36:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Build and return the tuple. */
|
2006-10-22 17:49:21 +00:00
|
|
|
tuple = heap_form_tuple(fctx->tupdesc, values, nulls);
|
2005-03-12 15:36:24 +00:00
|
|
|
result = HeapTupleGetDatum(tuple);
|
|
|
|
|
|
|
|
SRF_RETURN_NEXT(funcctx, result);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
SRF_RETURN_DONE(funcctx);
|
|
|
|
}
|
2022-10-13 09:55:46 -07:00
|
|
|
|
Add pg_buffercache_numa view with NUMA node info
Introduces a new view pg_buffercache_numa, showing NUMA memory nodes
for individual buffers. For each buffer the view returns an entry for
each memory page, with the associated NUMA node.
The database blocks and OS memory pages may have different size - the
default block size is 8KB, while the memory page is 4K (on x86). But
other combinations are possible, depending on configure parameters,
platform, etc. This means buffers may overlap with multiple memory
pages, each associated with a different NUMA node.
To determine the NUMA node for a buffer, we first need to touch the
memory pages using pg_numa_touch_mem_if_required, otherwise we might get
status -2 (ENOENT = The page is not present), indicating the page is
either unmapped or unallocated.
The view may be relatively expensive, especially when accessed for the
first time in a backend, as it touches all memory pages to get reliable
information about the NUMA node. This may also force allocation of the
shared memory.
Author: Jakub Wartak <jakub.wartak@enterprisedb.com>
Reviewed-by: Andres Freund <andres@anarazel.de>
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Reviewed-by: Tomas Vondra <tomas@vondra.me>
Discussion: https://postgr.es/m/CAKZiRmxh6KWo0aqRqvmcoaX2jUxZYb4kGp3N%3Dq1w%2BDiH-696Xw%40mail.gmail.com
2025-04-07 22:56:57 +02:00
|
|
|
/*
|
|
|
|
* Inquire about NUMA memory mappings for shared buffers.
|
|
|
|
*
|
|
|
|
* Returns NUMA node ID for each memory page used by the buffer. Buffers may
|
|
|
|
* be smaller or larger than OS memory pages. For each buffer we return one
|
2025-04-19 19:17:42 +09:00
|
|
|
* entry for each memory page used by the buffer (if the buffer is smaller,
|
Add pg_buffercache_numa view with NUMA node info
Introduces a new view pg_buffercache_numa, showing NUMA memory nodes
for individual buffers. For each buffer the view returns an entry for
each memory page, with the associated NUMA node.
The database blocks and OS memory pages may have different size - the
default block size is 8KB, while the memory page is 4K (on x86). But
other combinations are possible, depending on configure parameters,
platform, etc. This means buffers may overlap with multiple memory
pages, each associated with a different NUMA node.
To determine the NUMA node for a buffer, we first need to touch the
memory pages using pg_numa_touch_mem_if_required, otherwise we might get
status -2 (ENOENT = The page is not present), indicating the page is
either unmapped or unallocated.
The view may be relatively expensive, especially when accessed for the
first time in a backend, as it touches all memory pages to get reliable
information about the NUMA node. This may also force allocation of the
shared memory.
Author: Jakub Wartak <jakub.wartak@enterprisedb.com>
Reviewed-by: Andres Freund <andres@anarazel.de>
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Reviewed-by: Tomas Vondra <tomas@vondra.me>
Discussion: https://postgr.es/m/CAKZiRmxh6KWo0aqRqvmcoaX2jUxZYb4kGp3N%3Dq1w%2BDiH-696Xw%40mail.gmail.com
2025-04-07 22:56:57 +02:00
|
|
|
* it only uses a part of one memory page).
|
|
|
|
*
|
|
|
|
* We expect both sizes (for buffers and memory pages) to be a power-of-2, so
|
|
|
|
* one is always a multiple of the other.
|
|
|
|
*
|
|
|
|
* In order to get reliable results we also need to touch memory pages, so
|
|
|
|
* that the inquiry about NUMA memory node doesn't return -2 (which indicates
|
|
|
|
* unmapped/unallocated pages).
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
pg_buffercache_numa_pages(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
FuncCallContext *funcctx;
|
|
|
|
MemoryContext oldcontext;
|
|
|
|
BufferCacheNumaContext *fctx; /* User function context. */
|
|
|
|
TupleDesc tupledesc;
|
|
|
|
TupleDesc expected_tupledesc;
|
|
|
|
HeapTuple tuple;
|
|
|
|
Datum result;
|
|
|
|
|
|
|
|
if (SRF_IS_FIRSTCALL())
|
|
|
|
{
|
|
|
|
int i,
|
|
|
|
idx;
|
|
|
|
Size os_page_size;
|
|
|
|
void **os_page_ptrs;
|
|
|
|
int *os_page_status;
|
|
|
|
uint64 os_page_count;
|
|
|
|
int pages_per_buffer;
|
|
|
|
int max_entries;
|
|
|
|
volatile uint64 touch pg_attribute_unused();
|
|
|
|
char *startptr,
|
|
|
|
*endptr;
|
|
|
|
|
|
|
|
if (pg_numa_init() == -1)
|
|
|
|
elog(ERROR, "libnuma initialization failed or NUMA is not supported on this platform");
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The database block size and OS memory page size are unlikely to be
|
|
|
|
* the same. The block size is 1-32KB, the memory page size depends on
|
|
|
|
* platform. On x86 it's usually 4KB, on ARM it's 4KB or 64KB, but
|
|
|
|
* there are also features like THP etc. Moreover, we don't quite know
|
|
|
|
* how the pages and buffers "align" in memory - the buffers may be
|
|
|
|
* shifted in some way, using more memory pages than necessary.
|
|
|
|
*
|
2025-04-19 19:17:42 +09:00
|
|
|
* So we need to be careful about mapping buffers to memory pages. We
|
Add pg_buffercache_numa view with NUMA node info
Introduces a new view pg_buffercache_numa, showing NUMA memory nodes
for individual buffers. For each buffer the view returns an entry for
each memory page, with the associated NUMA node.
The database blocks and OS memory pages may have different size - the
default block size is 8KB, while the memory page is 4K (on x86). But
other combinations are possible, depending on configure parameters,
platform, etc. This means buffers may overlap with multiple memory
pages, each associated with a different NUMA node.
To determine the NUMA node for a buffer, we first need to touch the
memory pages using pg_numa_touch_mem_if_required, otherwise we might get
status -2 (ENOENT = The page is not present), indicating the page is
either unmapped or unallocated.
The view may be relatively expensive, especially when accessed for the
first time in a backend, as it touches all memory pages to get reliable
information about the NUMA node. This may also force allocation of the
shared memory.
Author: Jakub Wartak <jakub.wartak@enterprisedb.com>
Reviewed-by: Andres Freund <andres@anarazel.de>
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Reviewed-by: Tomas Vondra <tomas@vondra.me>
Discussion: https://postgr.es/m/CAKZiRmxh6KWo0aqRqvmcoaX2jUxZYb4kGp3N%3Dq1w%2BDiH-696Xw%40mail.gmail.com
2025-04-07 22:56:57 +02:00
|
|
|
* calculate the maximum number of pages a buffer might use, so that
|
|
|
|
* we allocate enough space for the entries. And then we count the
|
|
|
|
* actual number of entries as we scan the buffers.
|
|
|
|
*
|
|
|
|
* This information is needed before calling move_pages() for NUMA
|
|
|
|
* node id inquiry.
|
|
|
|
*/
|
2025-04-09 19:32:17 +02:00
|
|
|
os_page_size = pg_get_shmem_pagesize();
|
Add pg_buffercache_numa view with NUMA node info
Introduces a new view pg_buffercache_numa, showing NUMA memory nodes
for individual buffers. For each buffer the view returns an entry for
each memory page, with the associated NUMA node.
The database blocks and OS memory pages may have different size - the
default block size is 8KB, while the memory page is 4K (on x86). But
other combinations are possible, depending on configure parameters,
platform, etc. This means buffers may overlap with multiple memory
pages, each associated with a different NUMA node.
To determine the NUMA node for a buffer, we first need to touch the
memory pages using pg_numa_touch_mem_if_required, otherwise we might get
status -2 (ENOENT = The page is not present), indicating the page is
either unmapped or unallocated.
The view may be relatively expensive, especially when accessed for the
first time in a backend, as it touches all memory pages to get reliable
information about the NUMA node. This may also force allocation of the
shared memory.
Author: Jakub Wartak <jakub.wartak@enterprisedb.com>
Reviewed-by: Andres Freund <andres@anarazel.de>
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Reviewed-by: Tomas Vondra <tomas@vondra.me>
Discussion: https://postgr.es/m/CAKZiRmxh6KWo0aqRqvmcoaX2jUxZYb4kGp3N%3Dq1w%2BDiH-696Xw%40mail.gmail.com
2025-04-07 22:56:57 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The pages and block size is expected to be 2^k, so one divides the
|
|
|
|
* other (we don't know in which direction). This does not say
|
|
|
|
* anything about relative alignment of pages/buffers.
|
|
|
|
*/
|
|
|
|
Assert((os_page_size % BLCKSZ == 0) || (BLCKSZ % os_page_size == 0));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* How many addresses we are going to query? Simply get the page for
|
|
|
|
* the first buffer, and first page after the last buffer, and count
|
|
|
|
* the pages from that.
|
|
|
|
*/
|
|
|
|
startptr = (char *) TYPEALIGN_DOWN(os_page_size,
|
|
|
|
BufferGetBlock(1));
|
|
|
|
endptr = (char *) TYPEALIGN(os_page_size,
|
|
|
|
(char *) BufferGetBlock(NBuffers) + BLCKSZ);
|
|
|
|
os_page_count = (endptr - startptr) / os_page_size;
|
|
|
|
|
|
|
|
/* Used to determine the NUMA node for all OS pages at once */
|
|
|
|
os_page_ptrs = palloc0(sizeof(void *) * os_page_count);
|
|
|
|
os_page_status = palloc(sizeof(uint64) * os_page_count);
|
|
|
|
|
|
|
|
/* Fill pointers for all the memory pages. */
|
|
|
|
idx = 0;
|
|
|
|
for (char *ptr = startptr; ptr < endptr; ptr += os_page_size)
|
|
|
|
{
|
|
|
|
os_page_ptrs[idx++] = ptr;
|
|
|
|
|
|
|
|
/* Only need to touch memory once per backend process lifetime */
|
|
|
|
if (firstNumaTouch)
|
|
|
|
pg_numa_touch_mem_if_required(touch, ptr);
|
|
|
|
}
|
|
|
|
|
|
|
|
Assert(idx == os_page_count);
|
|
|
|
|
|
|
|
elog(DEBUG1, "NUMA: NBuffers=%d os_page_count=" UINT64_FORMAT " "
|
|
|
|
"os_page_size=%zu", NBuffers, os_page_count, os_page_size);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we ever get 0xff back from kernel inquiry, then we probably have
|
|
|
|
* bug in our buffers to OS page mapping code here.
|
|
|
|
*/
|
|
|
|
memset(os_page_status, 0xff, sizeof(int) * os_page_count);
|
|
|
|
|
|
|
|
/* Query NUMA status for all the pointers */
|
|
|
|
if (pg_numa_query_pages(0, os_page_count, os_page_ptrs, os_page_status) == -1)
|
|
|
|
elog(ERROR, "failed NUMA pages inquiry: %m");
|
|
|
|
|
|
|
|
/* Initialize the multi-call context, load entries about buffers */
|
|
|
|
|
|
|
|
funcctx = SRF_FIRSTCALL_INIT();
|
|
|
|
|
|
|
|
/* Switch context when allocating stuff to be used in later calls */
|
|
|
|
oldcontext = MemoryContextSwitchTo(funcctx->multi_call_memory_ctx);
|
|
|
|
|
|
|
|
/* Create a user function context for cross-call persistence */
|
|
|
|
fctx = (BufferCacheNumaContext *) palloc(sizeof(BufferCacheNumaContext));
|
|
|
|
|
|
|
|
if (get_call_result_type(fcinfo, NULL, &expected_tupledesc) != TYPEFUNC_COMPOSITE)
|
|
|
|
elog(ERROR, "return type must be a row type");
|
|
|
|
|
|
|
|
if (expected_tupledesc->natts != NUM_BUFFERCACHE_NUMA_ELEM)
|
|
|
|
elog(ERROR, "incorrect number of output arguments");
|
|
|
|
|
|
|
|
/* Construct a tuple descriptor for the result rows. */
|
|
|
|
tupledesc = CreateTemplateTupleDesc(expected_tupledesc->natts);
|
|
|
|
TupleDescInitEntry(tupledesc, (AttrNumber) 1, "bufferid",
|
|
|
|
INT4OID, -1, 0);
|
|
|
|
TupleDescInitEntry(tupledesc, (AttrNumber) 2, "os_page_num",
|
2025-04-08 11:52:02 +02:00
|
|
|
INT8OID, -1, 0);
|
Add pg_buffercache_numa view with NUMA node info
Introduces a new view pg_buffercache_numa, showing NUMA memory nodes
for individual buffers. For each buffer the view returns an entry for
each memory page, with the associated NUMA node.
The database blocks and OS memory pages may have different size - the
default block size is 8KB, while the memory page is 4K (on x86). But
other combinations are possible, depending on configure parameters,
platform, etc. This means buffers may overlap with multiple memory
pages, each associated with a different NUMA node.
To determine the NUMA node for a buffer, we first need to touch the
memory pages using pg_numa_touch_mem_if_required, otherwise we might get
status -2 (ENOENT = The page is not present), indicating the page is
either unmapped or unallocated.
The view may be relatively expensive, especially when accessed for the
first time in a backend, as it touches all memory pages to get reliable
information about the NUMA node. This may also force allocation of the
shared memory.
Author: Jakub Wartak <jakub.wartak@enterprisedb.com>
Reviewed-by: Andres Freund <andres@anarazel.de>
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Reviewed-by: Tomas Vondra <tomas@vondra.me>
Discussion: https://postgr.es/m/CAKZiRmxh6KWo0aqRqvmcoaX2jUxZYb4kGp3N%3Dq1w%2BDiH-696Xw%40mail.gmail.com
2025-04-07 22:56:57 +02:00
|
|
|
TupleDescInitEntry(tupledesc, (AttrNumber) 3, "numa_node",
|
|
|
|
INT4OID, -1, 0);
|
|
|
|
|
|
|
|
fctx->tupdesc = BlessTupleDesc(tupledesc);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Each buffer needs at least one entry, but it might be offset in
|
|
|
|
* some way, and use one extra entry. So we allocate space for the
|
|
|
|
* maximum number of entries we might need, and then count the exact
|
|
|
|
* number as we're walking buffers. That way we can do it in one pass,
|
|
|
|
* without reallocating memory.
|
|
|
|
*/
|
|
|
|
pages_per_buffer = Max(1, BLCKSZ / os_page_size) + 1;
|
|
|
|
max_entries = NBuffers * pages_per_buffer;
|
|
|
|
|
|
|
|
/* Allocate entries for BufferCachePagesRec records. */
|
|
|
|
fctx->record = (BufferCacheNumaRec *)
|
|
|
|
MemoryContextAllocHuge(CurrentMemoryContext,
|
|
|
|
sizeof(BufferCacheNumaRec) * max_entries);
|
|
|
|
|
|
|
|
/* Return to original context when allocating transient memory */
|
|
|
|
MemoryContextSwitchTo(oldcontext);
|
|
|
|
|
|
|
|
if (firstNumaTouch)
|
|
|
|
elog(DEBUG1, "NUMA: page-faulting the buffercache for proper NUMA readouts");
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Scan through all the buffers, saving the relevant fields in the
|
|
|
|
* fctx->record structure.
|
|
|
|
*
|
|
|
|
* We don't hold the partition locks, so we don't get a consistent
|
|
|
|
* snapshot across all buffers, but we do grab the buffer header
|
|
|
|
* locks, so the information of each buffer is self-consistent.
|
|
|
|
*
|
|
|
|
* This loop touches and stores addresses into os_page_ptrs[] as input
|
2025-04-21 10:41:18 +12:00
|
|
|
* to one big move_pages(2) inquiry system call. Basically we ask for
|
|
|
|
* all memory pages for NBuffers.
|
Add pg_buffercache_numa view with NUMA node info
Introduces a new view pg_buffercache_numa, showing NUMA memory nodes
for individual buffers. For each buffer the view returns an entry for
each memory page, with the associated NUMA node.
The database blocks and OS memory pages may have different size - the
default block size is 8KB, while the memory page is 4K (on x86). But
other combinations are possible, depending on configure parameters,
platform, etc. This means buffers may overlap with multiple memory
pages, each associated with a different NUMA node.
To determine the NUMA node for a buffer, we first need to touch the
memory pages using pg_numa_touch_mem_if_required, otherwise we might get
status -2 (ENOENT = The page is not present), indicating the page is
either unmapped or unallocated.
The view may be relatively expensive, especially when accessed for the
first time in a backend, as it touches all memory pages to get reliable
information about the NUMA node. This may also force allocation of the
shared memory.
Author: Jakub Wartak <jakub.wartak@enterprisedb.com>
Reviewed-by: Andres Freund <andres@anarazel.de>
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Reviewed-by: Tomas Vondra <tomas@vondra.me>
Discussion: https://postgr.es/m/CAKZiRmxh6KWo0aqRqvmcoaX2jUxZYb4kGp3N%3Dq1w%2BDiH-696Xw%40mail.gmail.com
2025-04-07 22:56:57 +02:00
|
|
|
*/
|
|
|
|
startptr = (char *) TYPEALIGN_DOWN(os_page_size, (char *) BufferGetBlock(1));
|
|
|
|
idx = 0;
|
|
|
|
for (i = 0; i < NBuffers; i++)
|
|
|
|
{
|
|
|
|
char *buffptr = (char *) BufferGetBlock(i + 1);
|
|
|
|
BufferDesc *bufHdr;
|
|
|
|
uint32 buf_state;
|
|
|
|
uint32 bufferid;
|
|
|
|
int32 page_num;
|
|
|
|
char *startptr_buff,
|
|
|
|
*endptr_buff;
|
|
|
|
|
|
|
|
CHECK_FOR_INTERRUPTS();
|
|
|
|
|
|
|
|
bufHdr = GetBufferDescriptor(i);
|
|
|
|
|
|
|
|
/* Lock each buffer header before inspecting. */
|
|
|
|
buf_state = LockBufHdr(bufHdr);
|
|
|
|
bufferid = BufferDescriptorGetBuffer(bufHdr);
|
|
|
|
UnlockBufHdr(bufHdr, buf_state);
|
|
|
|
|
|
|
|
/* start of the first page of this buffer */
|
|
|
|
startptr_buff = (char *) TYPEALIGN_DOWN(os_page_size, buffptr);
|
|
|
|
|
|
|
|
/* end of the buffer (no need to align to memory page) */
|
|
|
|
endptr_buff = buffptr + BLCKSZ;
|
|
|
|
|
|
|
|
Assert(startptr_buff < endptr_buff);
|
|
|
|
|
|
|
|
/* calculate ID of the first page for this buffer */
|
|
|
|
page_num = (startptr_buff - startptr) / os_page_size;
|
|
|
|
|
|
|
|
/* Add an entry for each OS page overlapping with this buffer. */
|
|
|
|
for (char *ptr = startptr_buff; ptr < endptr_buff; ptr += os_page_size)
|
|
|
|
{
|
|
|
|
fctx->record[idx].bufferid = bufferid;
|
|
|
|
fctx->record[idx].page_num = page_num;
|
|
|
|
fctx->record[idx].numa_node = os_page_status[page_num];
|
|
|
|
|
|
|
|
/* advance to the next entry/page */
|
|
|
|
++idx;
|
|
|
|
++page_num;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
Assert((idx >= os_page_count) && (idx <= max_entries));
|
|
|
|
|
|
|
|
/* Set max calls and remember the user function context. */
|
|
|
|
funcctx->max_calls = idx;
|
|
|
|
funcctx->user_fctx = fctx;
|
|
|
|
|
|
|
|
/* Remember this backend touched the pages */
|
|
|
|
firstNumaTouch = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
funcctx = SRF_PERCALL_SETUP();
|
|
|
|
|
|
|
|
/* Get the saved state */
|
|
|
|
fctx = funcctx->user_fctx;
|
|
|
|
|
|
|
|
if (funcctx->call_cntr < funcctx->max_calls)
|
|
|
|
{
|
|
|
|
uint32 i = funcctx->call_cntr;
|
|
|
|
Datum values[NUM_BUFFERCACHE_NUMA_ELEM];
|
|
|
|
bool nulls[NUM_BUFFERCACHE_NUMA_ELEM];
|
|
|
|
|
|
|
|
values[0] = Int32GetDatum(fctx->record[i].bufferid);
|
|
|
|
nulls[0] = false;
|
|
|
|
|
2025-04-08 11:52:02 +02:00
|
|
|
values[1] = Int64GetDatum(fctx->record[i].page_num);
|
Add pg_buffercache_numa view with NUMA node info
Introduces a new view pg_buffercache_numa, showing NUMA memory nodes
for individual buffers. For each buffer the view returns an entry for
each memory page, with the associated NUMA node.
The database blocks and OS memory pages may have different size - the
default block size is 8KB, while the memory page is 4K (on x86). But
other combinations are possible, depending on configure parameters,
platform, etc. This means buffers may overlap with multiple memory
pages, each associated with a different NUMA node.
To determine the NUMA node for a buffer, we first need to touch the
memory pages using pg_numa_touch_mem_if_required, otherwise we might get
status -2 (ENOENT = The page is not present), indicating the page is
either unmapped or unallocated.
The view may be relatively expensive, especially when accessed for the
first time in a backend, as it touches all memory pages to get reliable
information about the NUMA node. This may also force allocation of the
shared memory.
Author: Jakub Wartak <jakub.wartak@enterprisedb.com>
Reviewed-by: Andres Freund <andres@anarazel.de>
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Reviewed-by: Tomas Vondra <tomas@vondra.me>
Discussion: https://postgr.es/m/CAKZiRmxh6KWo0aqRqvmcoaX2jUxZYb4kGp3N%3Dq1w%2BDiH-696Xw%40mail.gmail.com
2025-04-07 22:56:57 +02:00
|
|
|
nulls[1] = false;
|
|
|
|
|
|
|
|
values[2] = Int32GetDatum(fctx->record[i].numa_node);
|
|
|
|
nulls[2] = false;
|
|
|
|
|
|
|
|
/* Build and return the tuple. */
|
|
|
|
tuple = heap_form_tuple(fctx->tupdesc, values, nulls);
|
|
|
|
result = HeapTupleGetDatum(tuple);
|
|
|
|
|
|
|
|
SRF_RETURN_NEXT(funcctx, result);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
SRF_RETURN_DONE(funcctx);
|
|
|
|
}
|
|
|
|
|
2022-10-13 09:55:46 -07:00
|
|
|
Datum
|
|
|
|
pg_buffercache_summary(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
Datum result;
|
|
|
|
TupleDesc tupledesc;
|
|
|
|
HeapTuple tuple;
|
|
|
|
Datum values[NUM_BUFFERCACHE_SUMMARY_ELEM];
|
|
|
|
bool nulls[NUM_BUFFERCACHE_SUMMARY_ELEM];
|
|
|
|
|
|
|
|
int32 buffers_used = 0;
|
|
|
|
int32 buffers_unused = 0;
|
|
|
|
int32 buffers_dirty = 0;
|
|
|
|
int32 buffers_pinned = 0;
|
|
|
|
int64 usagecount_total = 0;
|
|
|
|
|
|
|
|
if (get_call_result_type(fcinfo, NULL, &tupledesc) != TYPEFUNC_COMPOSITE)
|
|
|
|
elog(ERROR, "return type must be a row type");
|
|
|
|
|
|
|
|
for (int i = 0; i < NBuffers; i++)
|
|
|
|
{
|
|
|
|
BufferDesc *bufHdr;
|
|
|
|
uint32 buf_state;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This function summarizes the state of all headers. Locking the
|
|
|
|
* buffer headers wouldn't provide an improved result as the state of
|
|
|
|
* the buffer can still change after we release the lock and it'd
|
|
|
|
* noticeably increase the cost of the function.
|
|
|
|
*/
|
|
|
|
bufHdr = GetBufferDescriptor(i);
|
|
|
|
buf_state = pg_atomic_read_u32(&bufHdr->state);
|
|
|
|
|
|
|
|
if (buf_state & BM_VALID)
|
|
|
|
{
|
|
|
|
buffers_used++;
|
|
|
|
usagecount_total += BUF_STATE_GET_USAGECOUNT(buf_state);
|
|
|
|
|
|
|
|
if (buf_state & BM_DIRTY)
|
|
|
|
buffers_dirty++;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
buffers_unused++;
|
|
|
|
|
|
|
|
if (BUF_STATE_GET_REFCOUNT(buf_state) > 0)
|
|
|
|
buffers_pinned++;
|
|
|
|
}
|
|
|
|
|
|
|
|
memset(nulls, 0, sizeof(nulls));
|
|
|
|
values[0] = Int32GetDatum(buffers_used);
|
|
|
|
values[1] = Int32GetDatum(buffers_unused);
|
|
|
|
values[2] = Int32GetDatum(buffers_dirty);
|
|
|
|
values[3] = Int32GetDatum(buffers_pinned);
|
|
|
|
|
|
|
|
if (buffers_used != 0)
|
|
|
|
values[4] = Float8GetDatum((double) usagecount_total / buffers_used);
|
|
|
|
else
|
|
|
|
nulls[4] = true;
|
|
|
|
|
|
|
|
/* Build and return the tuple. */
|
|
|
|
tuple = heap_form_tuple(tupledesc, values, nulls);
|
|
|
|
result = HeapTupleGetDatum(tuple);
|
|
|
|
|
|
|
|
PG_RETURN_DATUM(result);
|
|
|
|
}
|
2023-04-07 14:25:45 -04:00
|
|
|
|
|
|
|
Datum
|
|
|
|
pg_buffercache_usage_counts(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
ReturnSetInfo *rsinfo = (ReturnSetInfo *) fcinfo->resultinfo;
|
|
|
|
int usage_counts[BM_MAX_USAGE_COUNT + 1] = {0};
|
|
|
|
int dirty[BM_MAX_USAGE_COUNT + 1] = {0};
|
|
|
|
int pinned[BM_MAX_USAGE_COUNT + 1] = {0};
|
|
|
|
Datum values[NUM_BUFFERCACHE_USAGE_COUNTS_ELEM];
|
|
|
|
bool nulls[NUM_BUFFERCACHE_USAGE_COUNTS_ELEM] = {0};
|
|
|
|
|
|
|
|
InitMaterializedSRF(fcinfo, 0);
|
|
|
|
|
|
|
|
for (int i = 0; i < NBuffers; i++)
|
|
|
|
{
|
|
|
|
BufferDesc *bufHdr = GetBufferDescriptor(i);
|
|
|
|
uint32 buf_state = pg_atomic_read_u32(&bufHdr->state);
|
|
|
|
int usage_count;
|
|
|
|
|
|
|
|
usage_count = BUF_STATE_GET_USAGECOUNT(buf_state);
|
|
|
|
usage_counts[usage_count]++;
|
|
|
|
|
|
|
|
if (buf_state & BM_DIRTY)
|
|
|
|
dirty[usage_count]++;
|
|
|
|
|
|
|
|
if (BUF_STATE_GET_REFCOUNT(buf_state) > 0)
|
|
|
|
pinned[usage_count]++;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (int i = 0; i < BM_MAX_USAGE_COUNT + 1; i++)
|
|
|
|
{
|
|
|
|
values[0] = Int32GetDatum(i);
|
|
|
|
values[1] = Int32GetDatum(usage_counts[i]);
|
|
|
|
values[2] = Int32GetDatum(dirty[i]);
|
|
|
|
values[3] = Int32GetDatum(pinned[i]);
|
|
|
|
|
|
|
|
tuplestore_putvalues(rsinfo->setResult, rsinfo->setDesc, values, nulls);
|
|
|
|
}
|
|
|
|
|
|
|
|
return (Datum) 0;
|
|
|
|
}
|
2024-04-07 09:13:17 +12:00
|
|
|
|
2025-04-08 02:16:51 -04:00
|
|
|
/*
|
|
|
|
* Helper function to check if the user has superuser privileges.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
pg_buffercache_superuser_check(char *func_name)
|
|
|
|
{
|
|
|
|
if (!superuser())
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
|
|
|
|
errmsg("must be superuser to use %s()",
|
|
|
|
func_name)));
|
|
|
|
}
|
|
|
|
|
2024-04-07 09:13:17 +12:00
|
|
|
/*
|
|
|
|
* Try to evict a shared buffer.
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
pg_buffercache_evict(PG_FUNCTION_ARGS)
|
|
|
|
{
|
2025-04-08 02:16:51 -04:00
|
|
|
Datum result;
|
|
|
|
TupleDesc tupledesc;
|
|
|
|
HeapTuple tuple;
|
|
|
|
Datum values[NUM_BUFFERCACHE_EVICT_ELEM];
|
|
|
|
bool nulls[NUM_BUFFERCACHE_EVICT_ELEM] = {0};
|
|
|
|
|
2024-04-07 09:13:17 +12:00
|
|
|
Buffer buf = PG_GETARG_INT32(0);
|
2025-04-08 02:16:51 -04:00
|
|
|
bool buffer_flushed;
|
2024-04-07 09:13:17 +12:00
|
|
|
|
2025-04-08 02:16:51 -04:00
|
|
|
if (get_call_result_type(fcinfo, NULL, &tupledesc) != TYPEFUNC_COMPOSITE)
|
|
|
|
elog(ERROR, "return type must be a row type");
|
|
|
|
|
|
|
|
pg_buffercache_superuser_check("pg_buffercache_evict");
|
2024-04-07 09:13:17 +12:00
|
|
|
|
|
|
|
if (buf < 1 || buf > NBuffers)
|
|
|
|
elog(ERROR, "bad buffer ID: %d", buf);
|
|
|
|
|
2025-04-08 02:16:51 -04:00
|
|
|
values[0] = BoolGetDatum(EvictUnpinnedBuffer(buf, &buffer_flushed));
|
|
|
|
values[1] = BoolGetDatum(buffer_flushed);
|
|
|
|
|
|
|
|
tuple = heap_form_tuple(tupledesc, values, nulls);
|
|
|
|
result = HeapTupleGetDatum(tuple);
|
|
|
|
|
|
|
|
PG_RETURN_DATUM(result);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Try to evict specified relation.
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
pg_buffercache_evict_relation(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
Datum result;
|
|
|
|
TupleDesc tupledesc;
|
|
|
|
HeapTuple tuple;
|
|
|
|
Datum values[NUM_BUFFERCACHE_EVICT_RELATION_ELEM];
|
|
|
|
bool nulls[NUM_BUFFERCACHE_EVICT_RELATION_ELEM] = {0};
|
|
|
|
|
|
|
|
Oid relOid;
|
|
|
|
Relation rel;
|
|
|
|
|
|
|
|
int32 buffers_evicted = 0;
|
|
|
|
int32 buffers_flushed = 0;
|
|
|
|
int32 buffers_skipped = 0;
|
|
|
|
|
|
|
|
if (get_call_result_type(fcinfo, NULL, &tupledesc) != TYPEFUNC_COMPOSITE)
|
|
|
|
elog(ERROR, "return type must be a row type");
|
|
|
|
|
|
|
|
pg_buffercache_superuser_check("pg_buffercache_evict_relation");
|
|
|
|
|
|
|
|
relOid = PG_GETARG_OID(0);
|
|
|
|
|
|
|
|
rel = relation_open(relOid, AccessShareLock);
|
|
|
|
|
|
|
|
if (RelationUsesLocalBuffers(rel))
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
|
|
|
|
errmsg("relation uses local buffers, %s() is intended to be used for shared buffers only",
|
|
|
|
"pg_buffercache_evict_relation")));
|
|
|
|
|
|
|
|
EvictRelUnpinnedBuffers(rel, &buffers_evicted, &buffers_flushed,
|
|
|
|
&buffers_skipped);
|
|
|
|
|
|
|
|
relation_close(rel, AccessShareLock);
|
|
|
|
|
|
|
|
values[0] = Int32GetDatum(buffers_evicted);
|
|
|
|
values[1] = Int32GetDatum(buffers_flushed);
|
|
|
|
values[2] = Int32GetDatum(buffers_skipped);
|
|
|
|
|
|
|
|
tuple = heap_form_tuple(tupledesc, values, nulls);
|
|
|
|
result = HeapTupleGetDatum(tuple);
|
|
|
|
|
|
|
|
PG_RETURN_DATUM(result);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Try to evict all shared buffers.
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
pg_buffercache_evict_all(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
Datum result;
|
|
|
|
TupleDesc tupledesc;
|
|
|
|
HeapTuple tuple;
|
|
|
|
Datum values[NUM_BUFFERCACHE_EVICT_ALL_ELEM];
|
|
|
|
bool nulls[NUM_BUFFERCACHE_EVICT_ALL_ELEM] = {0};
|
|
|
|
|
|
|
|
int32 buffers_evicted = 0;
|
|
|
|
int32 buffers_flushed = 0;
|
|
|
|
int32 buffers_skipped = 0;
|
|
|
|
|
|
|
|
if (get_call_result_type(fcinfo, NULL, &tupledesc) != TYPEFUNC_COMPOSITE)
|
|
|
|
elog(ERROR, "return type must be a row type");
|
|
|
|
|
|
|
|
pg_buffercache_superuser_check("pg_buffercache_evict_all");
|
|
|
|
|
|
|
|
EvictAllUnpinnedBuffers(&buffers_evicted, &buffers_flushed,
|
|
|
|
&buffers_skipped);
|
|
|
|
|
|
|
|
values[0] = Int32GetDatum(buffers_evicted);
|
|
|
|
values[1] = Int32GetDatum(buffers_flushed);
|
|
|
|
values[2] = Int32GetDatum(buffers_skipped);
|
|
|
|
|
|
|
|
tuple = heap_form_tuple(tupledesc, values, nulls);
|
|
|
|
result = HeapTupleGetDatum(tuple);
|
|
|
|
|
|
|
|
PG_RETURN_DATUM(result);
|
2024-04-07 09:13:17 +12:00
|
|
|
}
|