2001-10-01 05:52:38 +04:00
|
|
|
/*
|
2010-09-21 00:08:53 +04:00
|
|
|
* contrib/pgstattuple/pgstattuple.c
|
2001-10-01 05:52:38 +04:00
|
|
|
*
|
2002-08-23 12:19:49 +04:00
|
|
|
* Copyright (c) 2001,2002 Tatsuo Ishii
|
2001-10-01 05:52:38 +04:00
|
|
|
*
|
|
|
|
* Permission to use, copy, modify, and distribute this software and
|
|
|
|
* its documentation for any purpose, without fee, and without a
|
|
|
|
* written agreement is hereby granted, provided that the above
|
|
|
|
* copyright notice and this paragraph and the following two
|
|
|
|
* paragraphs appear in all copies.
|
|
|
|
*
|
|
|
|
* IN NO EVENT SHALL THE AUTHOR BE LIABLE TO ANY PARTY FOR DIRECT,
|
|
|
|
* INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING
|
|
|
|
* LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS
|
|
|
|
* DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED
|
|
|
|
* OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
*
|
|
|
|
* THE AUTHOR SPECIFICALLY DISCLAIMS ANY WARRANTIES, INCLUDING, BUT NOT
|
|
|
|
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
|
|
|
|
* A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS ON AN "AS
|
|
|
|
* IS" BASIS, AND THE AUTHOR HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE,
|
|
|
|
* SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "postgres.h"
|
2001-12-19 23:28:41 +03:00
|
|
|
|
2006-07-06 06:18:07 +04:00
|
|
|
#include "access/gist_private.h"
|
|
|
|
#include "access/hash.h"
|
Don't include heapam.h from others headers.
heapam.h previously was included in a number of widely used
headers (e.g. execnodes.h, indirectly in executor.h, ...). That's
problematic on its own, as heapam.h contains a lot of low-level
details that don't need to be exposed that widely, but becomes more
problematic with the upcoming introduction of pluggable table storage
- it seems inappropriate for heapam.h to be included that widely
afterwards.
heapam.h was largely only included in other headers to get the
HeapScanDesc typedef (which was defined in heapam.h, even though
HeapScanDescData is defined in relscan.h). The better solution here
seems to be to just use the underlying struct (forward declared where
necessary). Similar for BulkInsertState.
Another problem was that LockTupleMode was used in executor.h - parts
of the file tried to cope without heapam.h, but due to the fact that
it indirectly included it, several subsequent violations of that goal
were not not noticed. We could just reuse the approach of declaring
parameters as int, but it seems nicer to move LockTupleMode to
lockoptions.h - that's not a perfect location, but also doesn't seem
bad.
As a number of files relied on implicitly included heapam.h, a
significant number of files grew an explicit include. It's quite
probably that a few external projects will need to do the same.
Author: Andres Freund
Reviewed-By: Alvaro Herrera
Discussion: https://postgr.es/m/20190114000701.y4ttcb74jpskkcfb@alap3.anarazel.de
2019-01-15 02:54:18 +03:00
|
|
|
#include "access/heapam.h"
|
2006-07-11 21:26:59 +04:00
|
|
|
#include "access/nbtree.h"
|
2008-06-19 04:46:06 +04:00
|
|
|
#include "access/relscan.h"
|
tableam: Add and use scan APIs.
Too allow table accesses to be not directly dependent on heap, several
new abstractions are needed. Specifically:
1) Heap scans need to be generalized into table scans. Do this by
introducing TableScanDesc, which will be the "base class" for
individual AMs. This contains the AM independent fields from
HeapScanDesc.
The previous heap_{beginscan,rescan,endscan} et al. have been
replaced with a table_ version.
There's no direct replacement for heap_getnext(), as that returned
a HeapTuple, which is undesirable for a other AMs. Instead there's
table_scan_getnextslot(). But note that heap_getnext() lives on,
it's still used widely to access catalog tables.
This is achieved by new scan_begin, scan_end, scan_rescan,
scan_getnextslot callbacks.
2) The portion of parallel scans that's shared between backends need
to be able to do so without the user doing per-AM work. To achieve
that new parallelscan_{estimate, initialize, reinitialize}
callbacks are introduced, which operate on a new
ParallelTableScanDesc, which again can be subclassed by AMs.
As it is likely that several AMs are going to be block oriented,
block oriented callbacks that can be shared between such AMs are
provided and used by heap. table_block_parallelscan_{estimate,
intiialize, reinitialize} as callbacks, and
table_block_parallelscan_{nextpage, init} for use in AMs. These
operate on a ParallelBlockTableScanDesc.
3) Index scans need to be able to access tables to return a tuple, and
there needs to be state across individual accesses to the heap to
store state like buffers. That's now handled by introducing a
sort-of-scan IndexFetchTable, which again is intended to be
subclassed by individual AMs (for heap IndexFetchHeap).
The relevant callbacks for an AM are index_fetch_{end, begin,
reset} to create the necessary state, and index_fetch_tuple to
retrieve an indexed tuple. Note that index_fetch_tuple
implementations need to be smarter than just blindly fetching the
tuples for AMs that have optimizations similar to heap's HOT - the
currently alive tuple in the update chain needs to be fetched if
appropriate.
Similar to table_scan_getnextslot(), it's undesirable to continue
to return HeapTuples. Thus index_fetch_heap (might want to rename
that later) now accepts a slot as an argument. Core code doesn't
have a lot of call sites performing index scans without going
through the systable_* API (in contrast to loads of heap_getnext
calls and working directly with HeapTuples).
Index scans now store the result of a search in
IndexScanDesc->xs_heaptid, rather than xs_ctup->t_self. As the
target is not generally a HeapTuple anymore that seems cleaner.
To be able to sensible adapt code to use the above, two further
callbacks have been introduced:
a) slot_callbacks returns a TupleTableSlotOps* suitable for creating
slots capable of holding a tuple of the AMs
type. table_slot_callbacks() and table_slot_create() are based
upon that, but have additional logic to deal with views, foreign
tables, etc.
While this change could have been done separately, nearly all the
call sites that needed to be adapted for the rest of this commit
also would have been needed to be adapted for
table_slot_callbacks(), making separation not worthwhile.
b) tuple_satisfies_snapshot checks whether the tuple in a slot is
currently visible according to a snapshot. That's required as a few
places now don't have a buffer + HeapTuple around, but a
slot (which in heap's case internally has that information).
Additionally a few infrastructure changes were needed:
I) SysScanDesc, as used by systable_{beginscan, getnext} et al. now
internally uses a slot to keep track of tuples. While
systable_getnext() still returns HeapTuples, and will so for the
foreseeable future, the index API (see 1) above) now only deals with
slots.
The remainder, and largest part, of this commit is then adjusting all
scans in postgres to use the new APIs.
Author: Andres Freund, Haribabu Kommi, Alvaro Herrera
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
2019-03-11 22:46:41 +03:00
|
|
|
#include "access/tableam.h"
|
2002-03-30 04:02:42 +03:00
|
|
|
#include "catalog/namespace.h"
|
2019-04-02 00:57:21 +03:00
|
|
|
#include "catalog/pg_am_d.h"
|
2007-08-27 03:59:50 +04:00
|
|
|
#include "funcapi.h"
|
|
|
|
#include "miscadmin.h"
|
2008-05-12 04:00:54 +04:00
|
|
|
#include "storage/bufmgr.h"
|
2008-05-16 21:31:17 +04:00
|
|
|
#include "storage/lmgr.h"
|
2017-01-21 04:29:53 +03:00
|
|
|
#include "utils/varlena.h"
|
2002-03-30 04:02:42 +03:00
|
|
|
|
2006-05-31 02:12:16 +04:00
|
|
|
PG_MODULE_MAGIC;
|
|
|
|
|
2001-10-01 05:52:38 +04:00
|
|
|
PG_FUNCTION_INFO_V1(pgstattuple);
|
2016-09-30 05:13:38 +03:00
|
|
|
PG_FUNCTION_INFO_V1(pgstattuple_v1_5);
|
2003-06-12 12:02:57 +04:00
|
|
|
PG_FUNCTION_INFO_V1(pgstattuplebyid);
|
2016-09-30 05:13:38 +03:00
|
|
|
PG_FUNCTION_INFO_V1(pgstattuplebyid_v1_5);
|
2001-10-01 05:52:38 +04:00
|
|
|
|
2006-07-06 06:18:07 +04:00
|
|
|
/*
|
|
|
|
* struct pgstattuple_type
|
|
|
|
*
|
|
|
|
* tuple_percent, dead_tuple_percent and free_percent are computable,
|
|
|
|
* so not defined here.
|
|
|
|
*/
|
|
|
|
typedef struct pgstattuple_type
|
|
|
|
{
|
|
|
|
uint64 table_len;
|
|
|
|
uint64 tuple_count;
|
|
|
|
uint64 tuple_len;
|
|
|
|
uint64 dead_tuple_count;
|
|
|
|
uint64 dead_tuple_len;
|
|
|
|
uint64 free_space; /* free/reusable space in bytes */
|
|
|
|
} pgstattuple_type;
|
2006-10-04 04:30:14 +04:00
|
|
|
|
2012-03-13 17:51:03 +04:00
|
|
|
typedef void (*pgstat_page) (pgstattuple_type *, Relation, BlockNumber,
|
|
|
|
BufferAccessStrategy);
|
2006-10-04 04:30:14 +04:00
|
|
|
|
2006-07-06 06:18:07 +04:00
|
|
|
static Datum build_pgstattuple_type(pgstattuple_type *stat,
|
|
|
|
FunctionCallInfo fcinfo);
|
|
|
|
static Datum pgstat_relation(Relation rel, FunctionCallInfo fcinfo);
|
|
|
|
static Datum pgstat_heap(Relation rel, FunctionCallInfo fcinfo);
|
|
|
|
static void pgstat_btree_page(pgstattuple_type *stat,
|
2012-03-13 17:51:03 +04:00
|
|
|
Relation rel, BlockNumber blkno,
|
|
|
|
BufferAccessStrategy bstrategy);
|
2006-07-06 06:18:07 +04:00
|
|
|
static void pgstat_hash_page(pgstattuple_type *stat,
|
2012-03-13 17:51:03 +04:00
|
|
|
Relation rel, BlockNumber blkno,
|
|
|
|
BufferAccessStrategy bstrategy);
|
2006-07-06 06:18:07 +04:00
|
|
|
static void pgstat_gist_page(pgstattuple_type *stat,
|
2012-03-13 17:51:03 +04:00
|
|
|
Relation rel, BlockNumber blkno,
|
|
|
|
BufferAccessStrategy bstrategy);
|
2006-09-04 06:03:04 +04:00
|
|
|
static Datum pgstat_index(Relation rel, BlockNumber start,
|
2006-07-06 06:18:07 +04:00
|
|
|
pgstat_page pagefn, FunctionCallInfo fcinfo);
|
|
|
|
static void pgstat_index_page(pgstattuple_type *stat, Page page,
|
|
|
|
OffsetNumber minoff, OffsetNumber maxoff);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* build_pgstattuple_type -- build a pgstattuple_type tuple
|
|
|
|
*/
|
|
|
|
static Datum
|
|
|
|
build_pgstattuple_type(pgstattuple_type *stat, FunctionCallInfo fcinfo)
|
|
|
|
{
|
|
|
|
#define NCOLUMNS 9
|
2018-03-15 18:10:41 +03:00
|
|
|
#define NCHARS 314
|
2006-07-06 06:18:07 +04:00
|
|
|
|
|
|
|
HeapTuple tuple;
|
|
|
|
char *values[NCOLUMNS];
|
|
|
|
char values_buf[NCOLUMNS][NCHARS];
|
|
|
|
int i;
|
|
|
|
double tuple_percent;
|
|
|
|
double dead_tuple_percent;
|
|
|
|
double free_percent; /* free/reusable space in % */
|
|
|
|
TupleDesc tupdesc;
|
|
|
|
AttInMetadata *attinmeta;
|
|
|
|
|
|
|
|
/* Build a tuple descriptor for our result type */
|
|
|
|
if (get_call_result_type(fcinfo, NULL, &tupdesc) != TYPEFUNC_COMPOSITE)
|
|
|
|
elog(ERROR, "return type must be a row type");
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Generate attribute metadata needed later to produce tuples from raw C
|
|
|
|
* strings
|
|
|
|
*/
|
|
|
|
attinmeta = TupleDescGetAttInMetadata(tupdesc);
|
|
|
|
|
|
|
|
if (stat->table_len == 0)
|
|
|
|
{
|
|
|
|
tuple_percent = 0.0;
|
|
|
|
dead_tuple_percent = 0.0;
|
|
|
|
free_percent = 0.0;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
tuple_percent = 100.0 * stat->tuple_len / stat->table_len;
|
|
|
|
dead_tuple_percent = 100.0 * stat->dead_tuple_len / stat->table_len;
|
|
|
|
free_percent = 100.0 * stat->free_space / stat->table_len;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Prepare a values array for constructing the tuple. This should be an
|
|
|
|
* array of C strings which will be processed later by the appropriate
|
|
|
|
* "in" functions.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < NCOLUMNS; i++)
|
|
|
|
values[i] = values_buf[i];
|
|
|
|
i = 0;
|
|
|
|
snprintf(values[i++], NCHARS, INT64_FORMAT, stat->table_len);
|
|
|
|
snprintf(values[i++], NCHARS, INT64_FORMAT, stat->tuple_count);
|
|
|
|
snprintf(values[i++], NCHARS, INT64_FORMAT, stat->tuple_len);
|
|
|
|
snprintf(values[i++], NCHARS, "%.2f", tuple_percent);
|
|
|
|
snprintf(values[i++], NCHARS, INT64_FORMAT, stat->dead_tuple_count);
|
|
|
|
snprintf(values[i++], NCHARS, INT64_FORMAT, stat->dead_tuple_len);
|
|
|
|
snprintf(values[i++], NCHARS, "%.2f", dead_tuple_percent);
|
|
|
|
snprintf(values[i++], NCHARS, INT64_FORMAT, stat->free_space);
|
|
|
|
snprintf(values[i++], NCHARS, "%.2f", free_percent);
|
2005-05-31 03:09:07 +04:00
|
|
|
|
2006-07-06 06:18:07 +04:00
|
|
|
/* build a tuple */
|
|
|
|
tuple = BuildTupleFromCStrings(attinmeta, values);
|
|
|
|
|
|
|
|
/* make the tuple into a datum */
|
|
|
|
return HeapTupleGetDatum(tuple);
|
|
|
|
}
|
2001-10-01 05:52:38 +04:00
|
|
|
|
|
|
|
/* ----------
|
|
|
|
* pgstattuple:
|
2002-08-23 12:19:49 +04:00
|
|
|
* returns live/dead tuples info
|
2001-10-01 05:52:38 +04:00
|
|
|
*
|
|
|
|
* C FUNCTION definition
|
2002-08-29 21:14:33 +04:00
|
|
|
* pgstattuple(text) returns pgstattuple_type
|
2016-09-30 05:13:38 +03:00
|
|
|
*
|
|
|
|
* The superuser() check here must be kept as the library might be upgraded
|
|
|
|
* without the extension being upgraded, meaning that in pre-1.5 installations
|
|
|
|
* these functions could be called by any user.
|
2001-10-01 05:52:38 +04:00
|
|
|
* ----------
|
|
|
|
*/
|
2002-08-23 12:19:49 +04:00
|
|
|
|
2001-10-01 05:52:38 +04:00
|
|
|
Datum
|
|
|
|
pgstattuple(PG_FUNCTION_ARGS)
|
|
|
|
{
|
2017-03-13 02:35:34 +03:00
|
|
|
text *relname = PG_GETARG_TEXT_PP(0);
|
2002-03-30 04:02:42 +03:00
|
|
|
RangeVar *relrv;
|
2001-10-01 05:52:38 +04:00
|
|
|
Relation rel;
|
2003-06-12 12:02:57 +04:00
|
|
|
|
2007-08-27 03:59:50 +04:00
|
|
|
if (!superuser())
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
|
2020-01-30 19:32:04 +03:00
|
|
|
errmsg("must be superuser to use pgstattuple functions")));
|
2007-08-27 03:59:50 +04:00
|
|
|
|
2003-06-12 12:02:57 +04:00
|
|
|
/* open relation */
|
2005-05-27 04:57:49 +04:00
|
|
|
relrv = makeRangeVarFromNameList(textToQualifiedNameList(relname));
|
2006-07-06 06:18:07 +04:00
|
|
|
rel = relation_openrv(relrv, AccessShareLock);
|
2003-06-12 12:02:57 +04:00
|
|
|
|
2006-07-06 06:18:07 +04:00
|
|
|
PG_RETURN_DATUM(pgstat_relation(rel, fcinfo));
|
2003-06-12 12:02:57 +04:00
|
|
|
}
|
|
|
|
|
2016-09-30 05:13:38 +03:00
|
|
|
/*
|
|
|
|
* As of pgstattuple version 1.5, we no longer need to check if the user
|
|
|
|
* is a superuser because we REVOKE EXECUTE on the function from PUBLIC.
|
|
|
|
* Users can then grant access to it based on their policies.
|
|
|
|
*
|
|
|
|
* Otherwise identical to pgstattuple (above).
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
pgstattuple_v1_5(PG_FUNCTION_ARGS)
|
|
|
|
{
|
2017-03-13 02:35:34 +03:00
|
|
|
text *relname = PG_GETARG_TEXT_PP(0);
|
2016-09-30 05:13:38 +03:00
|
|
|
RangeVar *relrv;
|
|
|
|
Relation rel;
|
|
|
|
|
|
|
|
/* open relation */
|
|
|
|
relrv = makeRangeVarFromNameList(textToQualifiedNameList(relname));
|
|
|
|
rel = relation_openrv(relrv, AccessShareLock);
|
|
|
|
|
|
|
|
PG_RETURN_DATUM(pgstat_relation(rel, fcinfo));
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Must keep superuser() check, see above. */
|
2003-06-12 12:02:57 +04:00
|
|
|
Datum
|
|
|
|
pgstattuplebyid(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
Oid relid = PG_GETARG_OID(0);
|
|
|
|
Relation rel;
|
|
|
|
|
2007-08-27 03:59:50 +04:00
|
|
|
if (!superuser())
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
|
2020-01-30 19:32:04 +03:00
|
|
|
errmsg("must be superuser to use pgstattuple functions")));
|
2007-08-27 03:59:50 +04:00
|
|
|
|
2003-06-12 12:02:57 +04:00
|
|
|
/* open relation */
|
2006-07-06 06:18:07 +04:00
|
|
|
rel = relation_open(relid, AccessShareLock);
|
2003-06-12 12:02:57 +04:00
|
|
|
|
2006-07-06 06:18:07 +04:00
|
|
|
PG_RETURN_DATUM(pgstat_relation(rel, fcinfo));
|
2003-06-12 12:02:57 +04:00
|
|
|
}
|
|
|
|
|
2016-09-30 05:13:38 +03:00
|
|
|
/* Remove superuser() check for 1.5 version, see above */
|
|
|
|
Datum
|
|
|
|
pgstattuplebyid_v1_5(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
Oid relid = PG_GETARG_OID(0);
|
|
|
|
Relation rel;
|
|
|
|
|
|
|
|
/* open relation */
|
|
|
|
rel = relation_open(relid, AccessShareLock);
|
|
|
|
|
|
|
|
PG_RETURN_DATUM(pgstat_relation(rel, fcinfo));
|
|
|
|
}
|
|
|
|
|
2003-06-12 12:02:57 +04:00
|
|
|
/*
|
2006-07-06 06:18:07 +04:00
|
|
|
* pgstat_relation
|
2003-06-12 12:02:57 +04:00
|
|
|
*/
|
|
|
|
static Datum
|
2006-07-06 06:18:07 +04:00
|
|
|
pgstat_relation(Relation rel, FunctionCallInfo fcinfo)
|
2003-06-12 12:02:57 +04:00
|
|
|
{
|
2006-07-06 06:18:07 +04:00
|
|
|
const char *err;
|
2002-08-23 12:19:49 +04:00
|
|
|
|
2009-04-01 02:54:31 +04:00
|
|
|
/*
|
|
|
|
* Reject attempts to read non-local temporary relations; we would be
|
|
|
|
* likely to get wrong data since we have no visibility into the owning
|
|
|
|
* session's local buffers.
|
|
|
|
*/
|
|
|
|
if (RELATION_IS_OTHER_TEMP(rel))
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
errmsg("cannot access temporary tables of other sessions")));
|
|
|
|
|
2021-12-03 15:38:26 +03:00
|
|
|
if (RELKIND_HAS_TABLE_AM(rel->rd_rel->relkind) ||
|
|
|
|
rel->rd_rel->relkind == RELKIND_SEQUENCE)
|
2006-07-06 06:18:07 +04:00
|
|
|
{
|
|
|
|
return pgstat_heap(rel, fcinfo);
|
2021-12-03 15:38:26 +03:00
|
|
|
}
|
|
|
|
else if (rel->rd_rel->relkind == RELKIND_INDEX)
|
|
|
|
{
|
2023-10-31 00:46:05 +03:00
|
|
|
/* see pgstatindex_impl */
|
|
|
|
if (!rel->rd_index->indisvalid)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
|
|
|
|
errmsg("index \"%s\" is not valid",
|
|
|
|
RelationGetRelationName(rel))));
|
|
|
|
|
2006-07-06 06:18:07 +04:00
|
|
|
switch (rel->rd_rel->relam)
|
|
|
|
{
|
|
|
|
case BTREE_AM_OID:
|
2006-09-04 06:03:04 +04:00
|
|
|
return pgstat_index(rel, BTREE_METAPAGE + 1,
|
|
|
|
pgstat_btree_page, fcinfo);
|
2006-07-06 06:18:07 +04:00
|
|
|
case HASH_AM_OID:
|
2006-09-04 06:03:04 +04:00
|
|
|
return pgstat_index(rel, HASH_METAPAGE + 1,
|
|
|
|
pgstat_hash_page, fcinfo);
|
2006-07-06 06:18:07 +04:00
|
|
|
case GIST_AM_OID:
|
2006-09-04 06:03:04 +04:00
|
|
|
return pgstat_index(rel, GIST_ROOT_BLKNO + 1,
|
|
|
|
pgstat_gist_page, fcinfo);
|
2006-07-06 06:18:07 +04:00
|
|
|
case GIN_AM_OID:
|
|
|
|
err = "gin index";
|
2006-10-04 04:30:14 +04:00
|
|
|
break;
|
2012-03-13 17:35:55 +04:00
|
|
|
case SPGIST_AM_OID:
|
|
|
|
err = "spgist index";
|
|
|
|
break;
|
2015-07-14 16:36:51 +03:00
|
|
|
case BRIN_AM_OID:
|
|
|
|
err = "brin index";
|
|
|
|
break;
|
2006-10-04 04:30:14 +04:00
|
|
|
default:
|
2006-07-06 06:18:07 +04:00
|
|
|
err = "unknown index";
|
2006-10-04 04:30:14 +04:00
|
|
|
break;
|
|
|
|
}
|
Improve error messages about mismatching relkind
Most error messages about a relkind that was not supported or
appropriate for the command was of the pattern
"relation \"%s\" is not a table, foreign table, or materialized view"
This style can become verbose and tedious to maintain. Moreover, it's
not very helpful: If I'm trying to create a comment on a TOAST table,
which is not supported, then the information that I could have created
a comment on a materialized view is pointless.
Instead, write the primary error message shorter and saying more
directly that what was attempted is not possible. Then, in the detail
message, explain that the operation is not supported for the relkind
the object was. To simplify that, add a new function
errdetail_relkind_not_supported() that does this.
In passing, make use of RELKIND_HAS_STORAGE() where appropriate,
instead of listing out the relkinds individually.
Reviewed-by: Michael Paquier <michael@paquier.xyz>
Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org>
Discussion: https://www.postgresql.org/message-id/flat/dc35a398-37d0-75ce-07ea-1dd71d98f8ec@2ndquadrant.com
2021-07-08 10:38:52 +03:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
errmsg("index \"%s\" (%s) is not supported",
|
|
|
|
RelationGetRelationName(rel), err)));
|
2021-12-03 15:38:26 +03:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
Improve error messages about mismatching relkind
Most error messages about a relkind that was not supported or
appropriate for the command was of the pattern
"relation \"%s\" is not a table, foreign table, or materialized view"
This style can become verbose and tedious to maintain. Moreover, it's
not very helpful: If I'm trying to create a comment on a TOAST table,
which is not supported, then the information that I could have created
a comment on a materialized view is pointless.
Instead, write the primary error message shorter and saying more
directly that what was attempted is not possible. Then, in the detail
message, explain that the operation is not supported for the relkind
the object was. To simplify that, add a new function
errdetail_relkind_not_supported() that does this.
In passing, make use of RELKIND_HAS_STORAGE() where appropriate,
instead of listing out the relkinds individually.
Reviewed-by: Michael Paquier <michael@paquier.xyz>
Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org>
Discussion: https://www.postgresql.org/message-id/flat/dc35a398-37d0-75ce-07ea-1dd71d98f8ec@2ndquadrant.com
2021-07-08 10:38:52 +03:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
errmsg("cannot get tuple-level statistics for relation \"%s\"",
|
|
|
|
RelationGetRelationName(rel)),
|
|
|
|
errdetail_relkind_not_supported(rel->rd_rel->relkind)));
|
2006-07-06 06:18:07 +04:00
|
|
|
}
|
2005-05-31 03:09:07 +04:00
|
|
|
|
2006-07-06 06:18:07 +04:00
|
|
|
return 0; /* should not happen */
|
|
|
|
}
|
2002-08-23 12:19:49 +04:00
|
|
|
|
2006-07-06 06:18:07 +04:00
|
|
|
/*
|
|
|
|
* pgstat_heap -- returns live/dead tuples info in a heap
|
|
|
|
*/
|
|
|
|
static Datum
|
|
|
|
pgstat_heap(Relation rel, FunctionCallInfo fcinfo)
|
|
|
|
{
|
tableam: Add and use scan APIs.
Too allow table accesses to be not directly dependent on heap, several
new abstractions are needed. Specifically:
1) Heap scans need to be generalized into table scans. Do this by
introducing TableScanDesc, which will be the "base class" for
individual AMs. This contains the AM independent fields from
HeapScanDesc.
The previous heap_{beginscan,rescan,endscan} et al. have been
replaced with a table_ version.
There's no direct replacement for heap_getnext(), as that returned
a HeapTuple, which is undesirable for a other AMs. Instead there's
table_scan_getnextslot(). But note that heap_getnext() lives on,
it's still used widely to access catalog tables.
This is achieved by new scan_begin, scan_end, scan_rescan,
scan_getnextslot callbacks.
2) The portion of parallel scans that's shared between backends need
to be able to do so without the user doing per-AM work. To achieve
that new parallelscan_{estimate, initialize, reinitialize}
callbacks are introduced, which operate on a new
ParallelTableScanDesc, which again can be subclassed by AMs.
As it is likely that several AMs are going to be block oriented,
block oriented callbacks that can be shared between such AMs are
provided and used by heap. table_block_parallelscan_{estimate,
intiialize, reinitialize} as callbacks, and
table_block_parallelscan_{nextpage, init} for use in AMs. These
operate on a ParallelBlockTableScanDesc.
3) Index scans need to be able to access tables to return a tuple, and
there needs to be state across individual accesses to the heap to
store state like buffers. That's now handled by introducing a
sort-of-scan IndexFetchTable, which again is intended to be
subclassed by individual AMs (for heap IndexFetchHeap).
The relevant callbacks for an AM are index_fetch_{end, begin,
reset} to create the necessary state, and index_fetch_tuple to
retrieve an indexed tuple. Note that index_fetch_tuple
implementations need to be smarter than just blindly fetching the
tuples for AMs that have optimizations similar to heap's HOT - the
currently alive tuple in the update chain needs to be fetched if
appropriate.
Similar to table_scan_getnextslot(), it's undesirable to continue
to return HeapTuples. Thus index_fetch_heap (might want to rename
that later) now accepts a slot as an argument. Core code doesn't
have a lot of call sites performing index scans without going
through the systable_* API (in contrast to loads of heap_getnext
calls and working directly with HeapTuples).
Index scans now store the result of a search in
IndexScanDesc->xs_heaptid, rather than xs_ctup->t_self. As the
target is not generally a HeapTuple anymore that seems cleaner.
To be able to sensible adapt code to use the above, two further
callbacks have been introduced:
a) slot_callbacks returns a TupleTableSlotOps* suitable for creating
slots capable of holding a tuple of the AMs
type. table_slot_callbacks() and table_slot_create() are based
upon that, but have additional logic to deal with views, foreign
tables, etc.
While this change could have been done separately, nearly all the
call sites that needed to be adapted for the rest of this commit
also would have been needed to be adapted for
table_slot_callbacks(), making separation not worthwhile.
b) tuple_satisfies_snapshot checks whether the tuple in a slot is
currently visible according to a snapshot. That's required as a few
places now don't have a buffer + HeapTuple around, but a
slot (which in heap's case internally has that information).
Additionally a few infrastructure changes were needed:
I) SysScanDesc, as used by systable_{beginscan, getnext} et al. now
internally uses a slot to keep track of tuples. While
systable_getnext() still returns HeapTuples, and will so for the
foreseeable future, the index API (see 1) above) now only deals with
slots.
The remainder, and largest part, of this commit is then adjusting all
scans in postgres to use the new APIs.
Author: Andres Freund, Haribabu Kommi, Alvaro Herrera
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
2019-03-11 22:46:41 +03:00
|
|
|
TableScanDesc scan;
|
|
|
|
HeapScanDesc hscan;
|
2006-07-06 06:18:07 +04:00
|
|
|
HeapTuple tuple;
|
|
|
|
BlockNumber nblocks;
|
|
|
|
BlockNumber block = 0; /* next block to count free space in */
|
|
|
|
BlockNumber tupblock;
|
|
|
|
Buffer buffer;
|
|
|
|
pgstattuple_type stat = {0};
|
2013-07-26 00:16:42 +04:00
|
|
|
SnapshotData SnapshotDirty;
|
2002-08-23 12:19:49 +04:00
|
|
|
|
2024-09-13 00:31:29 +03:00
|
|
|
/*
|
|
|
|
* Sequences always use heap AM, but they don't show that in the catalogs.
|
|
|
|
*/
|
|
|
|
if (rel->rd_rel->relkind != RELKIND_SEQUENCE &&
|
|
|
|
rel->rd_rel->relam != HEAP_TABLE_AM_OID)
|
2019-04-02 00:57:21 +03:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
errmsg("only heap AM is supported")));
|
|
|
|
|
2008-01-14 05:53:31 +03:00
|
|
|
/* Disable syncscan because we assume we scan from block zero upwards */
|
tableam: Add and use scan APIs.
Too allow table accesses to be not directly dependent on heap, several
new abstractions are needed. Specifically:
1) Heap scans need to be generalized into table scans. Do this by
introducing TableScanDesc, which will be the "base class" for
individual AMs. This contains the AM independent fields from
HeapScanDesc.
The previous heap_{beginscan,rescan,endscan} et al. have been
replaced with a table_ version.
There's no direct replacement for heap_getnext(), as that returned
a HeapTuple, which is undesirable for a other AMs. Instead there's
table_scan_getnextslot(). But note that heap_getnext() lives on,
it's still used widely to access catalog tables.
This is achieved by new scan_begin, scan_end, scan_rescan,
scan_getnextslot callbacks.
2) The portion of parallel scans that's shared between backends need
to be able to do so without the user doing per-AM work. To achieve
that new parallelscan_{estimate, initialize, reinitialize}
callbacks are introduced, which operate on a new
ParallelTableScanDesc, which again can be subclassed by AMs.
As it is likely that several AMs are going to be block oriented,
block oriented callbacks that can be shared between such AMs are
provided and used by heap. table_block_parallelscan_{estimate,
intiialize, reinitialize} as callbacks, and
table_block_parallelscan_{nextpage, init} for use in AMs. These
operate on a ParallelBlockTableScanDesc.
3) Index scans need to be able to access tables to return a tuple, and
there needs to be state across individual accesses to the heap to
store state like buffers. That's now handled by introducing a
sort-of-scan IndexFetchTable, which again is intended to be
subclassed by individual AMs (for heap IndexFetchHeap).
The relevant callbacks for an AM are index_fetch_{end, begin,
reset} to create the necessary state, and index_fetch_tuple to
retrieve an indexed tuple. Note that index_fetch_tuple
implementations need to be smarter than just blindly fetching the
tuples for AMs that have optimizations similar to heap's HOT - the
currently alive tuple in the update chain needs to be fetched if
appropriate.
Similar to table_scan_getnextslot(), it's undesirable to continue
to return HeapTuples. Thus index_fetch_heap (might want to rename
that later) now accepts a slot as an argument. Core code doesn't
have a lot of call sites performing index scans without going
through the systable_* API (in contrast to loads of heap_getnext
calls and working directly with HeapTuples).
Index scans now store the result of a search in
IndexScanDesc->xs_heaptid, rather than xs_ctup->t_self. As the
target is not generally a HeapTuple anymore that seems cleaner.
To be able to sensible adapt code to use the above, two further
callbacks have been introduced:
a) slot_callbacks returns a TupleTableSlotOps* suitable for creating
slots capable of holding a tuple of the AMs
type. table_slot_callbacks() and table_slot_create() are based
upon that, but have additional logic to deal with views, foreign
tables, etc.
While this change could have been done separately, nearly all the
call sites that needed to be adapted for the rest of this commit
also would have been needed to be adapted for
table_slot_callbacks(), making separation not worthwhile.
b) tuple_satisfies_snapshot checks whether the tuple in a slot is
currently visible according to a snapshot. That's required as a few
places now don't have a buffer + HeapTuple around, but a
slot (which in heap's case internally has that information).
Additionally a few infrastructure changes were needed:
I) SysScanDesc, as used by systable_{beginscan, getnext} et al. now
internally uses a slot to keep track of tuples. While
systable_getnext() still returns HeapTuples, and will so for the
foreseeable future, the index API (see 1) above) now only deals with
slots.
The remainder, and largest part, of this commit is then adjusting all
scans in postgres to use the new APIs.
Author: Andres Freund, Haribabu Kommi, Alvaro Herrera
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
2019-03-11 22:46:41 +03:00
|
|
|
scan = table_beginscan_strat(rel, SnapshotAny, 0, NULL, true, false);
|
|
|
|
hscan = (HeapScanDesc) scan;
|
|
|
|
|
2013-07-26 00:16:42 +04:00
|
|
|
InitDirtySnapshot(SnapshotDirty);
|
2001-10-25 09:50:21 +04:00
|
|
|
|
tableam: Add and use scan APIs.
Too allow table accesses to be not directly dependent on heap, several
new abstractions are needed. Specifically:
1) Heap scans need to be generalized into table scans. Do this by
introducing TableScanDesc, which will be the "base class" for
individual AMs. This contains the AM independent fields from
HeapScanDesc.
The previous heap_{beginscan,rescan,endscan} et al. have been
replaced with a table_ version.
There's no direct replacement for heap_getnext(), as that returned
a HeapTuple, which is undesirable for a other AMs. Instead there's
table_scan_getnextslot(). But note that heap_getnext() lives on,
it's still used widely to access catalog tables.
This is achieved by new scan_begin, scan_end, scan_rescan,
scan_getnextslot callbacks.
2) The portion of parallel scans that's shared between backends need
to be able to do so without the user doing per-AM work. To achieve
that new parallelscan_{estimate, initialize, reinitialize}
callbacks are introduced, which operate on a new
ParallelTableScanDesc, which again can be subclassed by AMs.
As it is likely that several AMs are going to be block oriented,
block oriented callbacks that can be shared between such AMs are
provided and used by heap. table_block_parallelscan_{estimate,
intiialize, reinitialize} as callbacks, and
table_block_parallelscan_{nextpage, init} for use in AMs. These
operate on a ParallelBlockTableScanDesc.
3) Index scans need to be able to access tables to return a tuple, and
there needs to be state across individual accesses to the heap to
store state like buffers. That's now handled by introducing a
sort-of-scan IndexFetchTable, which again is intended to be
subclassed by individual AMs (for heap IndexFetchHeap).
The relevant callbacks for an AM are index_fetch_{end, begin,
reset} to create the necessary state, and index_fetch_tuple to
retrieve an indexed tuple. Note that index_fetch_tuple
implementations need to be smarter than just blindly fetching the
tuples for AMs that have optimizations similar to heap's HOT - the
currently alive tuple in the update chain needs to be fetched if
appropriate.
Similar to table_scan_getnextslot(), it's undesirable to continue
to return HeapTuples. Thus index_fetch_heap (might want to rename
that later) now accepts a slot as an argument. Core code doesn't
have a lot of call sites performing index scans without going
through the systable_* API (in contrast to loads of heap_getnext
calls and working directly with HeapTuples).
Index scans now store the result of a search in
IndexScanDesc->xs_heaptid, rather than xs_ctup->t_self. As the
target is not generally a HeapTuple anymore that seems cleaner.
To be able to sensible adapt code to use the above, two further
callbacks have been introduced:
a) slot_callbacks returns a TupleTableSlotOps* suitable for creating
slots capable of holding a tuple of the AMs
type. table_slot_callbacks() and table_slot_create() are based
upon that, but have additional logic to deal with views, foreign
tables, etc.
While this change could have been done separately, nearly all the
call sites that needed to be adapted for the rest of this commit
also would have been needed to be adapted for
table_slot_callbacks(), making separation not worthwhile.
b) tuple_satisfies_snapshot checks whether the tuple in a slot is
currently visible according to a snapshot. That's required as a few
places now don't have a buffer + HeapTuple around, but a
slot (which in heap's case internally has that information).
Additionally a few infrastructure changes were needed:
I) SysScanDesc, as used by systable_{beginscan, getnext} et al. now
internally uses a slot to keep track of tuples. While
systable_getnext() still returns HeapTuples, and will so for the
foreseeable future, the index API (see 1) above) now only deals with
slots.
The remainder, and largest part, of this commit is then adjusting all
scans in postgres to use the new APIs.
Author: Andres Freund, Haribabu Kommi, Alvaro Herrera
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
2019-03-11 22:46:41 +03:00
|
|
|
nblocks = hscan->rs_nblocks; /* # blocks to be scanned */
|
2004-05-08 23:09:25 +04:00
|
|
|
|
2002-08-23 12:19:49 +04:00
|
|
|
/* scan the relation */
|
2002-05-21 03:51:44 +04:00
|
|
|
while ((tuple = heap_getnext(scan, ForwardScanDirection)) != NULL)
|
2001-10-01 05:52:38 +04:00
|
|
|
{
|
2010-04-02 20:16:51 +04:00
|
|
|
CHECK_FOR_INTERRUPTS();
|
|
|
|
|
2007-03-25 23:45:14 +04:00
|
|
|
/* must hold a buffer lock to call HeapTupleSatisfiesVisibility */
|
tableam: Add and use scan APIs.
Too allow table accesses to be not directly dependent on heap, several
new abstractions are needed. Specifically:
1) Heap scans need to be generalized into table scans. Do this by
introducing TableScanDesc, which will be the "base class" for
individual AMs. This contains the AM independent fields from
HeapScanDesc.
The previous heap_{beginscan,rescan,endscan} et al. have been
replaced with a table_ version.
There's no direct replacement for heap_getnext(), as that returned
a HeapTuple, which is undesirable for a other AMs. Instead there's
table_scan_getnextslot(). But note that heap_getnext() lives on,
it's still used widely to access catalog tables.
This is achieved by new scan_begin, scan_end, scan_rescan,
scan_getnextslot callbacks.
2) The portion of parallel scans that's shared between backends need
to be able to do so without the user doing per-AM work. To achieve
that new parallelscan_{estimate, initialize, reinitialize}
callbacks are introduced, which operate on a new
ParallelTableScanDesc, which again can be subclassed by AMs.
As it is likely that several AMs are going to be block oriented,
block oriented callbacks that can be shared between such AMs are
provided and used by heap. table_block_parallelscan_{estimate,
intiialize, reinitialize} as callbacks, and
table_block_parallelscan_{nextpage, init} for use in AMs. These
operate on a ParallelBlockTableScanDesc.
3) Index scans need to be able to access tables to return a tuple, and
there needs to be state across individual accesses to the heap to
store state like buffers. That's now handled by introducing a
sort-of-scan IndexFetchTable, which again is intended to be
subclassed by individual AMs (for heap IndexFetchHeap).
The relevant callbacks for an AM are index_fetch_{end, begin,
reset} to create the necessary state, and index_fetch_tuple to
retrieve an indexed tuple. Note that index_fetch_tuple
implementations need to be smarter than just blindly fetching the
tuples for AMs that have optimizations similar to heap's HOT - the
currently alive tuple in the update chain needs to be fetched if
appropriate.
Similar to table_scan_getnextslot(), it's undesirable to continue
to return HeapTuples. Thus index_fetch_heap (might want to rename
that later) now accepts a slot as an argument. Core code doesn't
have a lot of call sites performing index scans without going
through the systable_* API (in contrast to loads of heap_getnext
calls and working directly with HeapTuples).
Index scans now store the result of a search in
IndexScanDesc->xs_heaptid, rather than xs_ctup->t_self. As the
target is not generally a HeapTuple anymore that seems cleaner.
To be able to sensible adapt code to use the above, two further
callbacks have been introduced:
a) slot_callbacks returns a TupleTableSlotOps* suitable for creating
slots capable of holding a tuple of the AMs
type. table_slot_callbacks() and table_slot_create() are based
upon that, but have additional logic to deal with views, foreign
tables, etc.
While this change could have been done separately, nearly all the
call sites that needed to be adapted for the rest of this commit
also would have been needed to be adapted for
table_slot_callbacks(), making separation not worthwhile.
b) tuple_satisfies_snapshot checks whether the tuple in a slot is
currently visible according to a snapshot. That's required as a few
places now don't have a buffer + HeapTuple around, but a
slot (which in heap's case internally has that information).
Additionally a few infrastructure changes were needed:
I) SysScanDesc, as used by systable_{beginscan, getnext} et al. now
internally uses a slot to keep track of tuples. While
systable_getnext() still returns HeapTuples, and will so for the
foreseeable future, the index API (see 1) above) now only deals with
slots.
The remainder, and largest part, of this commit is then adjusting all
scans in postgres to use the new APIs.
Author: Andres Freund, Haribabu Kommi, Alvaro Herrera
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
2019-03-11 22:46:41 +03:00
|
|
|
LockBuffer(hscan->rs_cbuf, BUFFER_LOCK_SHARE);
|
2004-10-16 02:40:29 +04:00
|
|
|
|
tableam: Add and use scan APIs.
Too allow table accesses to be not directly dependent on heap, several
new abstractions are needed. Specifically:
1) Heap scans need to be generalized into table scans. Do this by
introducing TableScanDesc, which will be the "base class" for
individual AMs. This contains the AM independent fields from
HeapScanDesc.
The previous heap_{beginscan,rescan,endscan} et al. have been
replaced with a table_ version.
There's no direct replacement for heap_getnext(), as that returned
a HeapTuple, which is undesirable for a other AMs. Instead there's
table_scan_getnextslot(). But note that heap_getnext() lives on,
it's still used widely to access catalog tables.
This is achieved by new scan_begin, scan_end, scan_rescan,
scan_getnextslot callbacks.
2) The portion of parallel scans that's shared between backends need
to be able to do so without the user doing per-AM work. To achieve
that new parallelscan_{estimate, initialize, reinitialize}
callbacks are introduced, which operate on a new
ParallelTableScanDesc, which again can be subclassed by AMs.
As it is likely that several AMs are going to be block oriented,
block oriented callbacks that can be shared between such AMs are
provided and used by heap. table_block_parallelscan_{estimate,
intiialize, reinitialize} as callbacks, and
table_block_parallelscan_{nextpage, init} for use in AMs. These
operate on a ParallelBlockTableScanDesc.
3) Index scans need to be able to access tables to return a tuple, and
there needs to be state across individual accesses to the heap to
store state like buffers. That's now handled by introducing a
sort-of-scan IndexFetchTable, which again is intended to be
subclassed by individual AMs (for heap IndexFetchHeap).
The relevant callbacks for an AM are index_fetch_{end, begin,
reset} to create the necessary state, and index_fetch_tuple to
retrieve an indexed tuple. Note that index_fetch_tuple
implementations need to be smarter than just blindly fetching the
tuples for AMs that have optimizations similar to heap's HOT - the
currently alive tuple in the update chain needs to be fetched if
appropriate.
Similar to table_scan_getnextslot(), it's undesirable to continue
to return HeapTuples. Thus index_fetch_heap (might want to rename
that later) now accepts a slot as an argument. Core code doesn't
have a lot of call sites performing index scans without going
through the systable_* API (in contrast to loads of heap_getnext
calls and working directly with HeapTuples).
Index scans now store the result of a search in
IndexScanDesc->xs_heaptid, rather than xs_ctup->t_self. As the
target is not generally a HeapTuple anymore that seems cleaner.
To be able to sensible adapt code to use the above, two further
callbacks have been introduced:
a) slot_callbacks returns a TupleTableSlotOps* suitable for creating
slots capable of holding a tuple of the AMs
type. table_slot_callbacks() and table_slot_create() are based
upon that, but have additional logic to deal with views, foreign
tables, etc.
While this change could have been done separately, nearly all the
call sites that needed to be adapted for the rest of this commit
also would have been needed to be adapted for
table_slot_callbacks(), making separation not worthwhile.
b) tuple_satisfies_snapshot checks whether the tuple in a slot is
currently visible according to a snapshot. That's required as a few
places now don't have a buffer + HeapTuple around, but a
slot (which in heap's case internally has that information).
Additionally a few infrastructure changes were needed:
I) SysScanDesc, as used by systable_{beginscan, getnext} et al. now
internally uses a slot to keep track of tuples. While
systable_getnext() still returns HeapTuples, and will so for the
foreseeable future, the index API (see 1) above) now only deals with
slots.
The remainder, and largest part, of this commit is then adjusting all
scans in postgres to use the new APIs.
Author: Andres Freund, Haribabu Kommi, Alvaro Herrera
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
2019-03-11 22:46:41 +03:00
|
|
|
if (HeapTupleSatisfiesVisibility(tuple, &SnapshotDirty, hscan->rs_cbuf))
|
2001-10-25 09:50:21 +04:00
|
|
|
{
|
2006-07-06 06:18:07 +04:00
|
|
|
stat.tuple_len += tuple->t_len;
|
|
|
|
stat.tuple_count++;
|
2001-10-25 09:50:21 +04:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2006-07-06 06:18:07 +04:00
|
|
|
stat.dead_tuple_len += tuple->t_len;
|
|
|
|
stat.dead_tuple_count++;
|
2001-10-25 09:50:21 +04:00
|
|
|
}
|
|
|
|
|
tableam: Add and use scan APIs.
Too allow table accesses to be not directly dependent on heap, several
new abstractions are needed. Specifically:
1) Heap scans need to be generalized into table scans. Do this by
introducing TableScanDesc, which will be the "base class" for
individual AMs. This contains the AM independent fields from
HeapScanDesc.
The previous heap_{beginscan,rescan,endscan} et al. have been
replaced with a table_ version.
There's no direct replacement for heap_getnext(), as that returned
a HeapTuple, which is undesirable for a other AMs. Instead there's
table_scan_getnextslot(). But note that heap_getnext() lives on,
it's still used widely to access catalog tables.
This is achieved by new scan_begin, scan_end, scan_rescan,
scan_getnextslot callbacks.
2) The portion of parallel scans that's shared between backends need
to be able to do so without the user doing per-AM work. To achieve
that new parallelscan_{estimate, initialize, reinitialize}
callbacks are introduced, which operate on a new
ParallelTableScanDesc, which again can be subclassed by AMs.
As it is likely that several AMs are going to be block oriented,
block oriented callbacks that can be shared between such AMs are
provided and used by heap. table_block_parallelscan_{estimate,
intiialize, reinitialize} as callbacks, and
table_block_parallelscan_{nextpage, init} for use in AMs. These
operate on a ParallelBlockTableScanDesc.
3) Index scans need to be able to access tables to return a tuple, and
there needs to be state across individual accesses to the heap to
store state like buffers. That's now handled by introducing a
sort-of-scan IndexFetchTable, which again is intended to be
subclassed by individual AMs (for heap IndexFetchHeap).
The relevant callbacks for an AM are index_fetch_{end, begin,
reset} to create the necessary state, and index_fetch_tuple to
retrieve an indexed tuple. Note that index_fetch_tuple
implementations need to be smarter than just blindly fetching the
tuples for AMs that have optimizations similar to heap's HOT - the
currently alive tuple in the update chain needs to be fetched if
appropriate.
Similar to table_scan_getnextslot(), it's undesirable to continue
to return HeapTuples. Thus index_fetch_heap (might want to rename
that later) now accepts a slot as an argument. Core code doesn't
have a lot of call sites performing index scans without going
through the systable_* API (in contrast to loads of heap_getnext
calls and working directly with HeapTuples).
Index scans now store the result of a search in
IndexScanDesc->xs_heaptid, rather than xs_ctup->t_self. As the
target is not generally a HeapTuple anymore that seems cleaner.
To be able to sensible adapt code to use the above, two further
callbacks have been introduced:
a) slot_callbacks returns a TupleTableSlotOps* suitable for creating
slots capable of holding a tuple of the AMs
type. table_slot_callbacks() and table_slot_create() are based
upon that, but have additional logic to deal with views, foreign
tables, etc.
While this change could have been done separately, nearly all the
call sites that needed to be adapted for the rest of this commit
also would have been needed to be adapted for
table_slot_callbacks(), making separation not worthwhile.
b) tuple_satisfies_snapshot checks whether the tuple in a slot is
currently visible according to a snapshot. That's required as a few
places now don't have a buffer + HeapTuple around, but a
slot (which in heap's case internally has that information).
Additionally a few infrastructure changes were needed:
I) SysScanDesc, as used by systable_{beginscan, getnext} et al. now
internally uses a slot to keep track of tuples. While
systable_getnext() still returns HeapTuples, and will so for the
foreseeable future, the index API (see 1) above) now only deals with
slots.
The remainder, and largest part, of this commit is then adjusting all
scans in postgres to use the new APIs.
Author: Andres Freund, Haribabu Kommi, Alvaro Herrera
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
2019-03-11 22:46:41 +03:00
|
|
|
LockBuffer(hscan->rs_cbuf, BUFFER_LOCK_UNLOCK);
|
2004-10-16 02:40:29 +04:00
|
|
|
|
2001-12-19 23:28:41 +03:00
|
|
|
/*
|
|
|
|
* To avoid physically reading the table twice, try to do the
|
|
|
|
* free-space scan in parallel with the heap scan. However,
|
|
|
|
* heap_getnext may find no tuples on a given page, so we cannot
|
|
|
|
* simply examine the pages returned by the heap scan.
|
|
|
|
*/
|
2017-03-28 18:52:55 +03:00
|
|
|
tupblock = ItemPointerGetBlockNumber(&tuple->t_self);
|
2001-12-19 23:28:41 +03:00
|
|
|
|
|
|
|
while (block <= tupblock)
|
2001-10-25 09:50:21 +04:00
|
|
|
{
|
2010-04-02 20:16:51 +04:00
|
|
|
CHECK_FOR_INTERRUPTS();
|
|
|
|
|
2014-07-01 00:59:19 +04:00
|
|
|
buffer = ReadBufferExtended(rel, MAIN_FORKNUM, block,
|
tableam: Add and use scan APIs.
Too allow table accesses to be not directly dependent on heap, several
new abstractions are needed. Specifically:
1) Heap scans need to be generalized into table scans. Do this by
introducing TableScanDesc, which will be the "base class" for
individual AMs. This contains the AM independent fields from
HeapScanDesc.
The previous heap_{beginscan,rescan,endscan} et al. have been
replaced with a table_ version.
There's no direct replacement for heap_getnext(), as that returned
a HeapTuple, which is undesirable for a other AMs. Instead there's
table_scan_getnextslot(). But note that heap_getnext() lives on,
it's still used widely to access catalog tables.
This is achieved by new scan_begin, scan_end, scan_rescan,
scan_getnextslot callbacks.
2) The portion of parallel scans that's shared between backends need
to be able to do so without the user doing per-AM work. To achieve
that new parallelscan_{estimate, initialize, reinitialize}
callbacks are introduced, which operate on a new
ParallelTableScanDesc, which again can be subclassed by AMs.
As it is likely that several AMs are going to be block oriented,
block oriented callbacks that can be shared between such AMs are
provided and used by heap. table_block_parallelscan_{estimate,
intiialize, reinitialize} as callbacks, and
table_block_parallelscan_{nextpage, init} for use in AMs. These
operate on a ParallelBlockTableScanDesc.
3) Index scans need to be able to access tables to return a tuple, and
there needs to be state across individual accesses to the heap to
store state like buffers. That's now handled by introducing a
sort-of-scan IndexFetchTable, which again is intended to be
subclassed by individual AMs (for heap IndexFetchHeap).
The relevant callbacks for an AM are index_fetch_{end, begin,
reset} to create the necessary state, and index_fetch_tuple to
retrieve an indexed tuple. Note that index_fetch_tuple
implementations need to be smarter than just blindly fetching the
tuples for AMs that have optimizations similar to heap's HOT - the
currently alive tuple in the update chain needs to be fetched if
appropriate.
Similar to table_scan_getnextslot(), it's undesirable to continue
to return HeapTuples. Thus index_fetch_heap (might want to rename
that later) now accepts a slot as an argument. Core code doesn't
have a lot of call sites performing index scans without going
through the systable_* API (in contrast to loads of heap_getnext
calls and working directly with HeapTuples).
Index scans now store the result of a search in
IndexScanDesc->xs_heaptid, rather than xs_ctup->t_self. As the
target is not generally a HeapTuple anymore that seems cleaner.
To be able to sensible adapt code to use the above, two further
callbacks have been introduced:
a) slot_callbacks returns a TupleTableSlotOps* suitable for creating
slots capable of holding a tuple of the AMs
type. table_slot_callbacks() and table_slot_create() are based
upon that, but have additional logic to deal with views, foreign
tables, etc.
While this change could have been done separately, nearly all the
call sites that needed to be adapted for the rest of this commit
also would have been needed to be adapted for
table_slot_callbacks(), making separation not worthwhile.
b) tuple_satisfies_snapshot checks whether the tuple in a slot is
currently visible according to a snapshot. That's required as a few
places now don't have a buffer + HeapTuple around, but a
slot (which in heap's case internally has that information).
Additionally a few infrastructure changes were needed:
I) SysScanDesc, as used by systable_{beginscan, getnext} et al. now
internally uses a slot to keep track of tuples. While
systable_getnext() still returns HeapTuples, and will so for the
foreseeable future, the index API (see 1) above) now only deals with
slots.
The remainder, and largest part, of this commit is then adjusting all
scans in postgres to use the new APIs.
Author: Andres Freund, Haribabu Kommi, Alvaro Herrera
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
2019-03-11 22:46:41 +03:00
|
|
|
RBM_NORMAL, hscan->rs_strategy);
|
2004-10-16 02:40:29 +04:00
|
|
|
LockBuffer(buffer, BUFFER_LOCK_SHARE);
|
Consistently use PageGetExactFreeSpace() in pgstattuple.
Previously this code used PageGetHeapFreeSpace on heap pages,
and usually used PageGetFreeSpace on index pages (though for some
reason GetHashPageStats used PageGetExactFreeSpace instead).
The difference is that those functions subtract off the size of
a line pointer, and PageGetHeapFreeSpace has some additional
rules about returning zero if adding another line pointer would
require exceeding MaxHeapTuplesPerPage. Those things make sense
when testing to see if a new tuple can be put on the page, but
they seem pretty strange for pure statistics collection.
Additionally, statapprox_heap had a special rule about counting
a "new" page as being fully available space. This also seems
strange, because it's not actually usable until VACUUM or some
such process initializes the page. Moreover, it's inconsistent
with what pgstat_heap does, which is to count such a page as
having zero free space. So make it work like pgstat_heap, which
as of this patch unconditionally calls PageGetExactFreeSpace.
This is more of a definitional change than a bug fix, so no
back-patch. The module's documentation doesn't define exactly
what "free space" means either, so we left that as-is.
Frédéric Yhuel, reviewed by Rafia Sabih and Andreas Karlsson.
Discussion: https://postgr.es/m/3a18f843-76f6-4a84-8cca-49537fefa15d@dalibo.com
2024-09-09 21:34:10 +03:00
|
|
|
stat.free_space += PageGetExactFreeSpace((Page) BufferGetPage(buffer));
|
2007-10-22 21:29:35 +04:00
|
|
|
UnlockReleaseBuffer(buffer);
|
2001-12-19 23:28:41 +03:00
|
|
|
block++;
|
2001-10-25 09:50:21 +04:00
|
|
|
}
|
2001-10-01 05:52:38 +04:00
|
|
|
}
|
2001-12-19 23:28:41 +03:00
|
|
|
|
|
|
|
while (block < nblocks)
|
|
|
|
{
|
2010-04-02 20:16:51 +04:00
|
|
|
CHECK_FOR_INTERRUPTS();
|
|
|
|
|
2014-07-01 00:59:19 +04:00
|
|
|
buffer = ReadBufferExtended(rel, MAIN_FORKNUM, block,
|
tableam: Add and use scan APIs.
Too allow table accesses to be not directly dependent on heap, several
new abstractions are needed. Specifically:
1) Heap scans need to be generalized into table scans. Do this by
introducing TableScanDesc, which will be the "base class" for
individual AMs. This contains the AM independent fields from
HeapScanDesc.
The previous heap_{beginscan,rescan,endscan} et al. have been
replaced with a table_ version.
There's no direct replacement for heap_getnext(), as that returned
a HeapTuple, which is undesirable for a other AMs. Instead there's
table_scan_getnextslot(). But note that heap_getnext() lives on,
it's still used widely to access catalog tables.
This is achieved by new scan_begin, scan_end, scan_rescan,
scan_getnextslot callbacks.
2) The portion of parallel scans that's shared between backends need
to be able to do so without the user doing per-AM work. To achieve
that new parallelscan_{estimate, initialize, reinitialize}
callbacks are introduced, which operate on a new
ParallelTableScanDesc, which again can be subclassed by AMs.
As it is likely that several AMs are going to be block oriented,
block oriented callbacks that can be shared between such AMs are
provided and used by heap. table_block_parallelscan_{estimate,
intiialize, reinitialize} as callbacks, and
table_block_parallelscan_{nextpage, init} for use in AMs. These
operate on a ParallelBlockTableScanDesc.
3) Index scans need to be able to access tables to return a tuple, and
there needs to be state across individual accesses to the heap to
store state like buffers. That's now handled by introducing a
sort-of-scan IndexFetchTable, which again is intended to be
subclassed by individual AMs (for heap IndexFetchHeap).
The relevant callbacks for an AM are index_fetch_{end, begin,
reset} to create the necessary state, and index_fetch_tuple to
retrieve an indexed tuple. Note that index_fetch_tuple
implementations need to be smarter than just blindly fetching the
tuples for AMs that have optimizations similar to heap's HOT - the
currently alive tuple in the update chain needs to be fetched if
appropriate.
Similar to table_scan_getnextslot(), it's undesirable to continue
to return HeapTuples. Thus index_fetch_heap (might want to rename
that later) now accepts a slot as an argument. Core code doesn't
have a lot of call sites performing index scans without going
through the systable_* API (in contrast to loads of heap_getnext
calls and working directly with HeapTuples).
Index scans now store the result of a search in
IndexScanDesc->xs_heaptid, rather than xs_ctup->t_self. As the
target is not generally a HeapTuple anymore that seems cleaner.
To be able to sensible adapt code to use the above, two further
callbacks have been introduced:
a) slot_callbacks returns a TupleTableSlotOps* suitable for creating
slots capable of holding a tuple of the AMs
type. table_slot_callbacks() and table_slot_create() are based
upon that, but have additional logic to deal with views, foreign
tables, etc.
While this change could have been done separately, nearly all the
call sites that needed to be adapted for the rest of this commit
also would have been needed to be adapted for
table_slot_callbacks(), making separation not worthwhile.
b) tuple_satisfies_snapshot checks whether the tuple in a slot is
currently visible according to a snapshot. That's required as a few
places now don't have a buffer + HeapTuple around, but a
slot (which in heap's case internally has that information).
Additionally a few infrastructure changes were needed:
I) SysScanDesc, as used by systable_{beginscan, getnext} et al. now
internally uses a slot to keep track of tuples. While
systable_getnext() still returns HeapTuples, and will so for the
foreseeable future, the index API (see 1) above) now only deals with
slots.
The remainder, and largest part, of this commit is then adjusting all
scans in postgres to use the new APIs.
Author: Andres Freund, Haribabu Kommi, Alvaro Herrera
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
2019-03-11 22:46:41 +03:00
|
|
|
RBM_NORMAL, hscan->rs_strategy);
|
2007-10-22 21:29:35 +04:00
|
|
|
LockBuffer(buffer, BUFFER_LOCK_SHARE);
|
Consistently use PageGetExactFreeSpace() in pgstattuple.
Previously this code used PageGetHeapFreeSpace on heap pages,
and usually used PageGetFreeSpace on index pages (though for some
reason GetHashPageStats used PageGetExactFreeSpace instead).
The difference is that those functions subtract off the size of
a line pointer, and PageGetHeapFreeSpace has some additional
rules about returning zero if adding another line pointer would
require exceeding MaxHeapTuplesPerPage. Those things make sense
when testing to see if a new tuple can be put on the page, but
they seem pretty strange for pure statistics collection.
Additionally, statapprox_heap had a special rule about counting
a "new" page as being fully available space. This also seems
strange, because it's not actually usable until VACUUM or some
such process initializes the page. Moreover, it's inconsistent
with what pgstat_heap does, which is to count such a page as
having zero free space. So make it work like pgstat_heap, which
as of this patch unconditionally calls PageGetExactFreeSpace.
This is more of a definitional change than a bug fix, so no
back-patch. The module's documentation doesn't define exactly
what "free space" means either, so we left that as-is.
Frédéric Yhuel, reviewed by Rafia Sabih and Andreas Karlsson.
Discussion: https://postgr.es/m/3a18f843-76f6-4a84-8cca-49537fefa15d@dalibo.com
2024-09-09 21:34:10 +03:00
|
|
|
stat.free_space += PageGetExactFreeSpace((Page) BufferGetPage(buffer));
|
2007-10-22 21:29:35 +04:00
|
|
|
UnlockReleaseBuffer(buffer);
|
2001-12-19 23:28:41 +03:00
|
|
|
block++;
|
|
|
|
}
|
|
|
|
|
tableam: Add and use scan APIs.
Too allow table accesses to be not directly dependent on heap, several
new abstractions are needed. Specifically:
1) Heap scans need to be generalized into table scans. Do this by
introducing TableScanDesc, which will be the "base class" for
individual AMs. This contains the AM independent fields from
HeapScanDesc.
The previous heap_{beginscan,rescan,endscan} et al. have been
replaced with a table_ version.
There's no direct replacement for heap_getnext(), as that returned
a HeapTuple, which is undesirable for a other AMs. Instead there's
table_scan_getnextslot(). But note that heap_getnext() lives on,
it's still used widely to access catalog tables.
This is achieved by new scan_begin, scan_end, scan_rescan,
scan_getnextslot callbacks.
2) The portion of parallel scans that's shared between backends need
to be able to do so without the user doing per-AM work. To achieve
that new parallelscan_{estimate, initialize, reinitialize}
callbacks are introduced, which operate on a new
ParallelTableScanDesc, which again can be subclassed by AMs.
As it is likely that several AMs are going to be block oriented,
block oriented callbacks that can be shared between such AMs are
provided and used by heap. table_block_parallelscan_{estimate,
intiialize, reinitialize} as callbacks, and
table_block_parallelscan_{nextpage, init} for use in AMs. These
operate on a ParallelBlockTableScanDesc.
3) Index scans need to be able to access tables to return a tuple, and
there needs to be state across individual accesses to the heap to
store state like buffers. That's now handled by introducing a
sort-of-scan IndexFetchTable, which again is intended to be
subclassed by individual AMs (for heap IndexFetchHeap).
The relevant callbacks for an AM are index_fetch_{end, begin,
reset} to create the necessary state, and index_fetch_tuple to
retrieve an indexed tuple. Note that index_fetch_tuple
implementations need to be smarter than just blindly fetching the
tuples for AMs that have optimizations similar to heap's HOT - the
currently alive tuple in the update chain needs to be fetched if
appropriate.
Similar to table_scan_getnextslot(), it's undesirable to continue
to return HeapTuples. Thus index_fetch_heap (might want to rename
that later) now accepts a slot as an argument. Core code doesn't
have a lot of call sites performing index scans without going
through the systable_* API (in contrast to loads of heap_getnext
calls and working directly with HeapTuples).
Index scans now store the result of a search in
IndexScanDesc->xs_heaptid, rather than xs_ctup->t_self. As the
target is not generally a HeapTuple anymore that seems cleaner.
To be able to sensible adapt code to use the above, two further
callbacks have been introduced:
a) slot_callbacks returns a TupleTableSlotOps* suitable for creating
slots capable of holding a tuple of the AMs
type. table_slot_callbacks() and table_slot_create() are based
upon that, but have additional logic to deal with views, foreign
tables, etc.
While this change could have been done separately, nearly all the
call sites that needed to be adapted for the rest of this commit
also would have been needed to be adapted for
table_slot_callbacks(), making separation not worthwhile.
b) tuple_satisfies_snapshot checks whether the tuple in a slot is
currently visible according to a snapshot. That's required as a few
places now don't have a buffer + HeapTuple around, but a
slot (which in heap's case internally has that information).
Additionally a few infrastructure changes were needed:
I) SysScanDesc, as used by systable_{beginscan, getnext} et al. now
internally uses a slot to keep track of tuples. While
systable_getnext() still returns HeapTuples, and will so for the
foreseeable future, the index API (see 1) above) now only deals with
slots.
The remainder, and largest part, of this commit is then adjusting all
scans in postgres to use the new APIs.
Author: Andres Freund, Haribabu Kommi, Alvaro Herrera
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
2019-03-11 22:46:41 +03:00
|
|
|
table_endscan(scan);
|
2006-07-06 06:18:07 +04:00
|
|
|
relation_close(rel, AccessShareLock);
|
|
|
|
|
|
|
|
stat.table_len = (uint64) nblocks * BLCKSZ;
|
|
|
|
|
|
|
|
return build_pgstattuple_type(&stat, fcinfo);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2006-09-04 06:03:04 +04:00
|
|
|
* pgstat_btree_page -- check tuples in a btree page
|
2006-07-06 06:18:07 +04:00
|
|
|
*/
|
|
|
|
static void
|
2012-03-13 17:51:03 +04:00
|
|
|
pgstat_btree_page(pgstattuple_type *stat, Relation rel, BlockNumber blkno,
|
|
|
|
BufferAccessStrategy bstrategy)
|
2006-07-06 06:18:07 +04:00
|
|
|
{
|
|
|
|
Buffer buf;
|
|
|
|
Page page;
|
|
|
|
|
2012-03-13 17:51:03 +04:00
|
|
|
buf = ReadBufferExtended(rel, MAIN_FORKNUM, blkno, RBM_NORMAL, bstrategy);
|
2006-07-06 06:18:07 +04:00
|
|
|
LockBuffer(buf, BT_READ);
|
2016-04-20 16:31:19 +03:00
|
|
|
page = BufferGetPage(buf);
|
2006-07-06 06:18:07 +04:00
|
|
|
|
|
|
|
/* Page is valid, see what to do with it */
|
|
|
|
if (PageIsNew(page))
|
2001-10-01 05:52:38 +04:00
|
|
|
{
|
2006-07-06 06:18:07 +04:00
|
|
|
/* fully empty page */
|
|
|
|
stat->free_space += BLCKSZ;
|
2001-10-01 05:52:38 +04:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2006-07-06 06:18:07 +04:00
|
|
|
BTPageOpaque opaque;
|
2006-10-04 04:30:14 +04:00
|
|
|
|
2022-04-01 07:24:50 +03:00
|
|
|
opaque = BTPageGetOpaque(page);
|
2017-09-18 23:36:28 +03:00
|
|
|
if (P_IGNORE(opaque))
|
2006-07-06 06:18:07 +04:00
|
|
|
{
|
2021-02-09 02:20:08 +03:00
|
|
|
/* deleted or half-dead page */
|
2006-07-06 06:18:07 +04:00
|
|
|
stat->free_space += BLCKSZ;
|
|
|
|
}
|
|
|
|
else if (P_ISLEAF(opaque))
|
|
|
|
{
|
|
|
|
pgstat_index_page(stat, page, P_FIRSTDATAKEY(opaque),
|
|
|
|
PageGetMaxOffsetNumber(page));
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2021-02-09 02:20:08 +03:00
|
|
|
/* internal page */
|
2006-07-06 06:18:07 +04:00
|
|
|
}
|
2001-10-01 05:52:38 +04:00
|
|
|
}
|
|
|
|
|
2006-07-06 06:18:07 +04:00
|
|
|
_bt_relbuf(rel, buf);
|
|
|
|
}
|
2002-09-05 00:31:48 +04:00
|
|
|
|
2006-07-06 06:18:07 +04:00
|
|
|
/*
|
2006-09-04 06:03:04 +04:00
|
|
|
* pgstat_hash_page -- check tuples in a hash page
|
2006-07-06 06:18:07 +04:00
|
|
|
*/
|
|
|
|
static void
|
2012-03-13 17:51:03 +04:00
|
|
|
pgstat_hash_page(pgstattuple_type *stat, Relation rel, BlockNumber blkno,
|
|
|
|
BufferAccessStrategy bstrategy)
|
2006-07-06 06:18:07 +04:00
|
|
|
{
|
|
|
|
Buffer buf;
|
|
|
|
Page page;
|
2002-09-05 00:31:48 +04:00
|
|
|
|
2012-03-13 17:51:03 +04:00
|
|
|
buf = _hash_getbuf_with_strategy(rel, blkno, HASH_READ, 0, bstrategy);
|
2016-04-20 16:31:19 +03:00
|
|
|
page = BufferGetPage(buf);
|
2006-07-06 06:18:07 +04:00
|
|
|
|
|
|
|
if (PageGetSpecialSize(page) == MAXALIGN(sizeof(HashPageOpaqueData)))
|
|
|
|
{
|
|
|
|
HashPageOpaque opaque;
|
2006-10-04 04:30:14 +04:00
|
|
|
|
2022-04-01 07:24:50 +03:00
|
|
|
opaque = HashPageGetOpaque(page);
|
2017-04-15 00:04:25 +03:00
|
|
|
switch (opaque->hasho_flag & LH_PAGE_TYPE)
|
2006-07-06 06:18:07 +04:00
|
|
|
{
|
|
|
|
case LH_UNUSED_PAGE:
|
|
|
|
stat->free_space += BLCKSZ;
|
|
|
|
break;
|
|
|
|
case LH_BUCKET_PAGE:
|
|
|
|
case LH_OVERFLOW_PAGE:
|
|
|
|
pgstat_index_page(stat, page, FirstOffsetNumber,
|
|
|
|
PageGetMaxOffsetNumber(page));
|
|
|
|
break;
|
|
|
|
case LH_BITMAP_PAGE:
|
|
|
|
case LH_META_PAGE:
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* maybe corrupted */
|
|
|
|
}
|
|
|
|
|
|
|
|
_hash_relbuf(rel, buf);
|
|
|
|
}
|
2002-09-05 00:31:48 +04:00
|
|
|
|
2006-07-06 06:18:07 +04:00
|
|
|
/*
|
2006-09-04 06:03:04 +04:00
|
|
|
* pgstat_gist_page -- check tuples in a gist page
|
2006-07-06 06:18:07 +04:00
|
|
|
*/
|
|
|
|
static void
|
2012-03-13 17:51:03 +04:00
|
|
|
pgstat_gist_page(pgstattuple_type *stat, Relation rel, BlockNumber blkno,
|
|
|
|
BufferAccessStrategy bstrategy)
|
2006-07-06 06:18:07 +04:00
|
|
|
{
|
|
|
|
Buffer buf;
|
|
|
|
Page page;
|
|
|
|
|
2012-03-13 17:51:03 +04:00
|
|
|
buf = ReadBufferExtended(rel, MAIN_FORKNUM, blkno, RBM_NORMAL, bstrategy);
|
2006-07-06 06:18:07 +04:00
|
|
|
LockBuffer(buf, GIST_SHARE);
|
|
|
|
gistcheckpage(rel, buf);
|
2016-04-20 16:31:19 +03:00
|
|
|
page = BufferGetPage(buf);
|
2006-07-06 06:18:07 +04:00
|
|
|
|
|
|
|
if (GistPageIsLeaf(page))
|
|
|
|
{
|
|
|
|
pgstat_index_page(stat, page, FirstOffsetNumber,
|
|
|
|
PageGetMaxOffsetNumber(page));
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* root or node */
|
|
|
|
}
|
|
|
|
|
|
|
|
UnlockReleaseBuffer(buf);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* pgstat_index -- returns live/dead tuples info in a generic index
|
|
|
|
*/
|
|
|
|
static Datum
|
2006-09-04 06:03:04 +04:00
|
|
|
pgstat_index(Relation rel, BlockNumber start, pgstat_page pagefn,
|
|
|
|
FunctionCallInfo fcinfo)
|
2006-07-06 06:18:07 +04:00
|
|
|
{
|
|
|
|
BlockNumber nblocks;
|
|
|
|
BlockNumber blkno;
|
2012-03-13 17:51:03 +04:00
|
|
|
BufferAccessStrategy bstrategy;
|
2006-09-04 06:03:04 +04:00
|
|
|
pgstattuple_type stat = {0};
|
2006-07-06 06:18:07 +04:00
|
|
|
|
2012-03-13 17:51:03 +04:00
|
|
|
/* prepare access strategy for this index */
|
|
|
|
bstrategy = GetAccessStrategy(BAS_BULKREAD);
|
|
|
|
|
2006-07-06 06:18:07 +04:00
|
|
|
blkno = start;
|
|
|
|
for (;;)
|
|
|
|
{
|
|
|
|
/* Get the current relation length */
|
|
|
|
LockRelationForExtension(rel, ExclusiveLock);
|
|
|
|
nblocks = RelationGetNumberOfBlocks(rel);
|
|
|
|
UnlockRelationForExtension(rel, ExclusiveLock);
|
|
|
|
|
|
|
|
/* Quit if we've scanned the whole relation */
|
|
|
|
if (blkno >= nblocks)
|
|
|
|
{
|
2006-09-04 06:03:04 +04:00
|
|
|
stat.table_len = (uint64) nblocks * BLCKSZ;
|
2006-10-04 04:30:14 +04:00
|
|
|
|
2006-07-06 06:18:07 +04:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (; blkno < nblocks; blkno++)
|
2010-04-02 20:16:51 +04:00
|
|
|
{
|
|
|
|
CHECK_FOR_INTERRUPTS();
|
|
|
|
|
2012-03-13 17:51:03 +04:00
|
|
|
pagefn(&stat, rel, blkno, bstrategy);
|
2010-04-02 20:16:51 +04:00
|
|
|
}
|
2006-07-06 06:18:07 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
relation_close(rel, AccessShareLock);
|
|
|
|
|
2006-09-04 06:03:04 +04:00
|
|
|
return build_pgstattuple_type(&stat, fcinfo);
|
2006-07-06 06:18:07 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* pgstat_index_page -- for generic index page
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
pgstat_index_page(pgstattuple_type *stat, Page page,
|
|
|
|
OffsetNumber minoff, OffsetNumber maxoff)
|
|
|
|
{
|
|
|
|
OffsetNumber i;
|
|
|
|
|
Consistently use PageGetExactFreeSpace() in pgstattuple.
Previously this code used PageGetHeapFreeSpace on heap pages,
and usually used PageGetFreeSpace on index pages (though for some
reason GetHashPageStats used PageGetExactFreeSpace instead).
The difference is that those functions subtract off the size of
a line pointer, and PageGetHeapFreeSpace has some additional
rules about returning zero if adding another line pointer would
require exceeding MaxHeapTuplesPerPage. Those things make sense
when testing to see if a new tuple can be put on the page, but
they seem pretty strange for pure statistics collection.
Additionally, statapprox_heap had a special rule about counting
a "new" page as being fully available space. This also seems
strange, because it's not actually usable until VACUUM or some
such process initializes the page. Moreover, it's inconsistent
with what pgstat_heap does, which is to count such a page as
having zero free space. So make it work like pgstat_heap, which
as of this patch unconditionally calls PageGetExactFreeSpace.
This is more of a definitional change than a bug fix, so no
back-patch. The module's documentation doesn't define exactly
what "free space" means either, so we left that as-is.
Frédéric Yhuel, reviewed by Rafia Sabih and Andreas Karlsson.
Discussion: https://postgr.es/m/3a18f843-76f6-4a84-8cca-49537fefa15d@dalibo.com
2024-09-09 21:34:10 +03:00
|
|
|
stat->free_space += PageGetExactFreeSpace(page);
|
2006-07-06 06:18:07 +04:00
|
|
|
|
|
|
|
for (i = minoff; i <= maxoff; i = OffsetNumberNext(i))
|
|
|
|
{
|
|
|
|
ItemId itemid = PageGetItemId(page, i);
|
|
|
|
|
2007-09-13 02:10:26 +04:00
|
|
|
if (ItemIdIsDead(itemid))
|
2006-07-06 06:18:07 +04:00
|
|
|
{
|
|
|
|
stat->dead_tuple_count++;
|
|
|
|
stat->dead_tuple_len += ItemIdGetLength(itemid);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
stat->tuple_count++;
|
|
|
|
stat->tuple_len += ItemIdGetLength(itemid);
|
|
|
|
}
|
|
|
|
}
|
2001-10-01 05:52:38 +04:00
|
|
|
}
|