2011-08-25 12:06:16 +08:00
|
|
|
CREATE EXTENSION pgstattuple;
|
|
|
|
|
--
|
|
|
|
|
-- It's difficult to come up with platform-independent test cases for
|
|
|
|
|
-- the pgstattuple functions, but the results for empty tables and
|
|
|
|
|
-- indexes should be that.
|
|
|
|
|
--
|
2012-12-05 15:58:03 +08:00
|
|
|
create table test (a int primary key, b int[]);
|
2013-07-19 02:50:20 +08:00
|
|
|
select * from pgstattuple('test');
|
|
|
|
|
table_len | tuple_count | tuple_len | tuple_percent | dead_tuple_count | dead_tuple_len | dead_tuple_percent | free_space | free_percent
|
|
|
|
|
-----------+-------------+-----------+---------------+------------------+----------------+--------------------+------------+--------------
|
|
|
|
|
0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0
|
|
|
|
|
(1 row)
|
|
|
|
|
|
2011-08-25 12:06:16 +08:00
|
|
|
select * from pgstattuple('test'::text);
|
|
|
|
|
table_len | tuple_count | tuple_len | tuple_percent | dead_tuple_count | dead_tuple_len | dead_tuple_percent | free_space | free_percent
|
|
|
|
|
-----------+-------------+-----------+---------------+------------------+----------------+--------------------+------------+--------------
|
|
|
|
|
0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0
|
|
|
|
|
(1 row)
|
|
|
|
|
|
2013-07-19 02:50:20 +08:00
|
|
|
select * from pgstattuple('test'::name);
|
|
|
|
|
table_len | tuple_count | tuple_len | tuple_percent | dead_tuple_count | dead_tuple_len | dead_tuple_percent | free_space | free_percent
|
|
|
|
|
-----------+-------------+-----------+---------------+------------------+----------------+--------------------+------------+--------------
|
|
|
|
|
0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0
|
|
|
|
|
(1 row)
|
|
|
|
|
|
2011-08-25 12:06:16 +08:00
|
|
|
select * from pgstattuple('test'::regclass);
|
|
|
|
|
table_len | tuple_count | tuple_len | tuple_percent | dead_tuple_count | dead_tuple_len | dead_tuple_percent | free_space | free_percent
|
|
|
|
|
-----------+-------------+-----------+---------------+------------------+----------------+--------------------+------------+--------------
|
|
|
|
|
0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0
|
|
|
|
|
(1 row)
|
|
|
|
|
|
2013-07-19 02:50:20 +08:00
|
|
|
select pgstattuple(oid) from pg_class where relname = 'test';
|
|
|
|
|
pgstattuple
|
|
|
|
|
---------------------
|
|
|
|
|
(0,0,0,0,0,0,0,0,0)
|
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
|
|
select pgstattuple(relname) from pg_class where relname = 'test';
|
|
|
|
|
pgstattuple
|
|
|
|
|
---------------------
|
|
|
|
|
(0,0,0,0,0,0,0,0,0)
|
|
|
|
|
(1 row)
|
|
|
|
|
|
Fix multiple bugs in contrib/pgstattuple's pgstatindex() function.
Dead or half-dead index leaf pages were incorrectly reported as live, as a
consequence of a code rearrangement I made (during a moment of severe brain
fade, evidently) in commit d287818eb514d431.
The index metapage was not counted in index_size, causing that result to
not agree with the actual index size on-disk.
Index root pages were not counted in internal_pages, which is inconsistent
compared to the case of a root that's also a leaf (one-page index), where
the root would be counted in leaf_pages. Aside from that inconsistency,
this could lead to additional transient discrepancies between the reported
page counts and index_size, since it's possible for pgstatindex's scan to
see zero or multiple pages marked as BTP_ROOT, if the root moves due to
a split during the scan. With these fixes, index_size will always be
exactly one page more than the sum of the displayed page counts.
Also, the index_size result was incorrectly documented as being measured in
pages; it's always been measured in bytes. (While fixing that, I couldn't
resist doing some small additional wordsmithing on the pgstattuple docs.)
Including the metapage causes the reported index_size to not be zero for
an empty index. To preserve the desired property that the pgstattuple
regression test results are platform-independent (ie, BLCKSZ configuration
independent), scale the index_size result in the regression tests.
The documentation issue was reported by Otsuka Kenji, and the inconsistent
root page counting by Peter Geoghegan; the other problems noted by me.
Back-patch to all supported branches, because this has been broken for
a long time.
2016-02-19 04:40:35 +08:00
|
|
|
select version, tree_level,
|
|
|
|
|
index_size / current_setting('block_size')::int as index_size,
|
|
|
|
|
root_block_no, internal_pages, leaf_pages, empty_pages, deleted_pages,
|
|
|
|
|
avg_leaf_density, leaf_fragmentation
|
|
|
|
|
from pgstatindex('test_pkey');
|
2011-08-25 12:06:16 +08:00
|
|
|
version | tree_level | index_size | root_block_no | internal_pages | leaf_pages | empty_pages | deleted_pages | avg_leaf_density | leaf_fragmentation
|
|
|
|
|
---------+------------+------------+---------------+----------------+------------+-------------+---------------+------------------+--------------------
|
Make heap TID a tiebreaker nbtree index column.
Make nbtree treat all index tuples as having a heap TID attribute.
Index searches can distinguish duplicates by heap TID, since heap TID is
always guaranteed to be unique. This general approach has numerous
benefits for performance, and is prerequisite to teaching VACUUM to
perform "retail index tuple deletion".
Naively adding a new attribute to every pivot tuple has unacceptable
overhead (it bloats internal pages), so suffix truncation of pivot
tuples is added. This will usually truncate away the "extra" heap TID
attribute from pivot tuples during a leaf page split, and may also
truncate away additional user attributes. This can increase fan-out,
especially in a multi-column index. Truncation can only occur at the
attribute granularity, which isn't particularly effective, but works
well enough for now. A future patch may add support for truncating
"within" text attributes by generating truncated key values using new
opclass infrastructure.
Only new indexes (BTREE_VERSION 4 indexes) will have insertions that
treat heap TID as a tiebreaker attribute, or will have pivot tuples
undergo suffix truncation during a leaf page split (on-disk
compatibility with versions 2 and 3 is preserved). Upgrades to version
4 cannot be performed on-the-fly, unlike upgrades from version 2 to
version 3. contrib/amcheck continues to work with version 2 and 3
indexes, while also enforcing stricter invariants when verifying version
4 indexes. These stricter invariants are the same invariants described
by "3.1.12 Sequencing" from the Lehman and Yao paper.
A later patch will enhance the logic used by nbtree to pick a split
point. This patch is likely to negatively impact performance without
smarter choices around the precise point to split leaf pages at. Making
these two mostly-distinct sets of enhancements into distinct commits
seems like it might clarify their design, even though neither commit is
particularly useful on its own.
The maximum allowed size of new tuples is reduced by an amount equal to
the space required to store an extra MAXALIGN()'d TID in a new high key
during leaf page splits. The user-facing definition of the "1/3 of a
page" restriction is already imprecise, and so does not need to be
revised. However, there should be a compatibility note in the v12
release notes.
Author: Peter Geoghegan
Reviewed-By: Heikki Linnakangas, Alexander Korotkov
Discussion: https://postgr.es/m/CAH2-WzkVb0Kom=R+88fDFb=JSxZMFvbHVC6Mn9LJ2n=X=kS-Uw@mail.gmail.com
2019-03-21 01:04:01 +08:00
|
|
|
4 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | NaN | NaN
|
2011-08-25 12:06:16 +08:00
|
|
|
(1 row)
|
|
|
|
|
|
Fix multiple bugs in contrib/pgstattuple's pgstatindex() function.
Dead or half-dead index leaf pages were incorrectly reported as live, as a
consequence of a code rearrangement I made (during a moment of severe brain
fade, evidently) in commit d287818eb514d431.
The index metapage was not counted in index_size, causing that result to
not agree with the actual index size on-disk.
Index root pages were not counted in internal_pages, which is inconsistent
compared to the case of a root that's also a leaf (one-page index), where
the root would be counted in leaf_pages. Aside from that inconsistency,
this could lead to additional transient discrepancies between the reported
page counts and index_size, since it's possible for pgstatindex's scan to
see zero or multiple pages marked as BTP_ROOT, if the root moves due to
a split during the scan. With these fixes, index_size will always be
exactly one page more than the sum of the displayed page counts.
Also, the index_size result was incorrectly documented as being measured in
pages; it's always been measured in bytes. (While fixing that, I couldn't
resist doing some small additional wordsmithing on the pgstattuple docs.)
Including the metapage causes the reported index_size to not be zero for
an empty index. To preserve the desired property that the pgstattuple
regression test results are platform-independent (ie, BLCKSZ configuration
independent), scale the index_size result in the regression tests.
The documentation issue was reported by Otsuka Kenji, and the inconsistent
root page counting by Peter Geoghegan; the other problems noted by me.
Back-patch to all supported branches, because this has been broken for
a long time.
2016-02-19 04:40:35 +08:00
|
|
|
select version, tree_level,
|
|
|
|
|
index_size / current_setting('block_size')::int as index_size,
|
|
|
|
|
root_block_no, internal_pages, leaf_pages, empty_pages, deleted_pages,
|
|
|
|
|
avg_leaf_density, leaf_fragmentation
|
|
|
|
|
from pgstatindex('test_pkey'::text);
|
2013-07-19 02:50:20 +08:00
|
|
|
version | tree_level | index_size | root_block_no | internal_pages | leaf_pages | empty_pages | deleted_pages | avg_leaf_density | leaf_fragmentation
|
|
|
|
|
---------+------------+------------+---------------+----------------+------------+-------------+---------------+------------------+--------------------
|
Make heap TID a tiebreaker nbtree index column.
Make nbtree treat all index tuples as having a heap TID attribute.
Index searches can distinguish duplicates by heap TID, since heap TID is
always guaranteed to be unique. This general approach has numerous
benefits for performance, and is prerequisite to teaching VACUUM to
perform "retail index tuple deletion".
Naively adding a new attribute to every pivot tuple has unacceptable
overhead (it bloats internal pages), so suffix truncation of pivot
tuples is added. This will usually truncate away the "extra" heap TID
attribute from pivot tuples during a leaf page split, and may also
truncate away additional user attributes. This can increase fan-out,
especially in a multi-column index. Truncation can only occur at the
attribute granularity, which isn't particularly effective, but works
well enough for now. A future patch may add support for truncating
"within" text attributes by generating truncated key values using new
opclass infrastructure.
Only new indexes (BTREE_VERSION 4 indexes) will have insertions that
treat heap TID as a tiebreaker attribute, or will have pivot tuples
undergo suffix truncation during a leaf page split (on-disk
compatibility with versions 2 and 3 is preserved). Upgrades to version
4 cannot be performed on-the-fly, unlike upgrades from version 2 to
version 3. contrib/amcheck continues to work with version 2 and 3
indexes, while also enforcing stricter invariants when verifying version
4 indexes. These stricter invariants are the same invariants described
by "3.1.12 Sequencing" from the Lehman and Yao paper.
A later patch will enhance the logic used by nbtree to pick a split
point. This patch is likely to negatively impact performance without
smarter choices around the precise point to split leaf pages at. Making
these two mostly-distinct sets of enhancements into distinct commits
seems like it might clarify their design, even though neither commit is
particularly useful on its own.
The maximum allowed size of new tuples is reduced by an amount equal to
the space required to store an extra MAXALIGN()'d TID in a new high key
during leaf page splits. The user-facing definition of the "1/3 of a
page" restriction is already imprecise, and so does not need to be
revised. However, there should be a compatibility note in the v12
release notes.
Author: Peter Geoghegan
Reviewed-By: Heikki Linnakangas, Alexander Korotkov
Discussion: https://postgr.es/m/CAH2-WzkVb0Kom=R+88fDFb=JSxZMFvbHVC6Mn9LJ2n=X=kS-Uw@mail.gmail.com
2019-03-21 01:04:01 +08:00
|
|
|
4 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | NaN | NaN
|
2013-07-19 02:50:20 +08:00
|
|
|
(1 row)
|
|
|
|
|
|
Fix multiple bugs in contrib/pgstattuple's pgstatindex() function.
Dead or half-dead index leaf pages were incorrectly reported as live, as a
consequence of a code rearrangement I made (during a moment of severe brain
fade, evidently) in commit d287818eb514d431.
The index metapage was not counted in index_size, causing that result to
not agree with the actual index size on-disk.
Index root pages were not counted in internal_pages, which is inconsistent
compared to the case of a root that's also a leaf (one-page index), where
the root would be counted in leaf_pages. Aside from that inconsistency,
this could lead to additional transient discrepancies between the reported
page counts and index_size, since it's possible for pgstatindex's scan to
see zero or multiple pages marked as BTP_ROOT, if the root moves due to
a split during the scan. With these fixes, index_size will always be
exactly one page more than the sum of the displayed page counts.
Also, the index_size result was incorrectly documented as being measured in
pages; it's always been measured in bytes. (While fixing that, I couldn't
resist doing some small additional wordsmithing on the pgstattuple docs.)
Including the metapage causes the reported index_size to not be zero for
an empty index. To preserve the desired property that the pgstattuple
regression test results are platform-independent (ie, BLCKSZ configuration
independent), scale the index_size result in the regression tests.
The documentation issue was reported by Otsuka Kenji, and the inconsistent
root page counting by Peter Geoghegan; the other problems noted by me.
Back-patch to all supported branches, because this has been broken for
a long time.
2016-02-19 04:40:35 +08:00
|
|
|
select version, tree_level,
|
|
|
|
|
index_size / current_setting('block_size')::int as index_size,
|
|
|
|
|
root_block_no, internal_pages, leaf_pages, empty_pages, deleted_pages,
|
|
|
|
|
avg_leaf_density, leaf_fragmentation
|
|
|
|
|
from pgstatindex('test_pkey'::name);
|
2013-07-19 02:50:20 +08:00
|
|
|
version | tree_level | index_size | root_block_no | internal_pages | leaf_pages | empty_pages | deleted_pages | avg_leaf_density | leaf_fragmentation
|
|
|
|
|
---------+------------+------------+---------------+----------------+------------+-------------+---------------+------------------+--------------------
|
Make heap TID a tiebreaker nbtree index column.
Make nbtree treat all index tuples as having a heap TID attribute.
Index searches can distinguish duplicates by heap TID, since heap TID is
always guaranteed to be unique. This general approach has numerous
benefits for performance, and is prerequisite to teaching VACUUM to
perform "retail index tuple deletion".
Naively adding a new attribute to every pivot tuple has unacceptable
overhead (it bloats internal pages), so suffix truncation of pivot
tuples is added. This will usually truncate away the "extra" heap TID
attribute from pivot tuples during a leaf page split, and may also
truncate away additional user attributes. This can increase fan-out,
especially in a multi-column index. Truncation can only occur at the
attribute granularity, which isn't particularly effective, but works
well enough for now. A future patch may add support for truncating
"within" text attributes by generating truncated key values using new
opclass infrastructure.
Only new indexes (BTREE_VERSION 4 indexes) will have insertions that
treat heap TID as a tiebreaker attribute, or will have pivot tuples
undergo suffix truncation during a leaf page split (on-disk
compatibility with versions 2 and 3 is preserved). Upgrades to version
4 cannot be performed on-the-fly, unlike upgrades from version 2 to
version 3. contrib/amcheck continues to work with version 2 and 3
indexes, while also enforcing stricter invariants when verifying version
4 indexes. These stricter invariants are the same invariants described
by "3.1.12 Sequencing" from the Lehman and Yao paper.
A later patch will enhance the logic used by nbtree to pick a split
point. This patch is likely to negatively impact performance without
smarter choices around the precise point to split leaf pages at. Making
these two mostly-distinct sets of enhancements into distinct commits
seems like it might clarify their design, even though neither commit is
particularly useful on its own.
The maximum allowed size of new tuples is reduced by an amount equal to
the space required to store an extra MAXALIGN()'d TID in a new high key
during leaf page splits. The user-facing definition of the "1/3 of a
page" restriction is already imprecise, and so does not need to be
revised. However, there should be a compatibility note in the v12
release notes.
Author: Peter Geoghegan
Reviewed-By: Heikki Linnakangas, Alexander Korotkov
Discussion: https://postgr.es/m/CAH2-WzkVb0Kom=R+88fDFb=JSxZMFvbHVC6Mn9LJ2n=X=kS-Uw@mail.gmail.com
2019-03-21 01:04:01 +08:00
|
|
|
4 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | NaN | NaN
|
2013-07-19 02:50:20 +08:00
|
|
|
(1 row)
|
|
|
|
|
|
Fix multiple bugs in contrib/pgstattuple's pgstatindex() function.
Dead or half-dead index leaf pages were incorrectly reported as live, as a
consequence of a code rearrangement I made (during a moment of severe brain
fade, evidently) in commit d287818eb514d431.
The index metapage was not counted in index_size, causing that result to
not agree with the actual index size on-disk.
Index root pages were not counted in internal_pages, which is inconsistent
compared to the case of a root that's also a leaf (one-page index), where
the root would be counted in leaf_pages. Aside from that inconsistency,
this could lead to additional transient discrepancies between the reported
page counts and index_size, since it's possible for pgstatindex's scan to
see zero or multiple pages marked as BTP_ROOT, if the root moves due to
a split during the scan. With these fixes, index_size will always be
exactly one page more than the sum of the displayed page counts.
Also, the index_size result was incorrectly documented as being measured in
pages; it's always been measured in bytes. (While fixing that, I couldn't
resist doing some small additional wordsmithing on the pgstattuple docs.)
Including the metapage causes the reported index_size to not be zero for
an empty index. To preserve the desired property that the pgstattuple
regression test results are platform-independent (ie, BLCKSZ configuration
independent), scale the index_size result in the regression tests.
The documentation issue was reported by Otsuka Kenji, and the inconsistent
root page counting by Peter Geoghegan; the other problems noted by me.
Back-patch to all supported branches, because this has been broken for
a long time.
2016-02-19 04:40:35 +08:00
|
|
|
select version, tree_level,
|
|
|
|
|
index_size / current_setting('block_size')::int as index_size,
|
|
|
|
|
root_block_no, internal_pages, leaf_pages, empty_pages, deleted_pages,
|
|
|
|
|
avg_leaf_density, leaf_fragmentation
|
|
|
|
|
from pgstatindex('test_pkey'::regclass);
|
2013-07-19 02:50:20 +08:00
|
|
|
version | tree_level | index_size | root_block_no | internal_pages | leaf_pages | empty_pages | deleted_pages | avg_leaf_density | leaf_fragmentation
|
|
|
|
|
---------+------------+------------+---------------+----------------+------------+-------------+---------------+------------------+--------------------
|
Make heap TID a tiebreaker nbtree index column.
Make nbtree treat all index tuples as having a heap TID attribute.
Index searches can distinguish duplicates by heap TID, since heap TID is
always guaranteed to be unique. This general approach has numerous
benefits for performance, and is prerequisite to teaching VACUUM to
perform "retail index tuple deletion".
Naively adding a new attribute to every pivot tuple has unacceptable
overhead (it bloats internal pages), so suffix truncation of pivot
tuples is added. This will usually truncate away the "extra" heap TID
attribute from pivot tuples during a leaf page split, and may also
truncate away additional user attributes. This can increase fan-out,
especially in a multi-column index. Truncation can only occur at the
attribute granularity, which isn't particularly effective, but works
well enough for now. A future patch may add support for truncating
"within" text attributes by generating truncated key values using new
opclass infrastructure.
Only new indexes (BTREE_VERSION 4 indexes) will have insertions that
treat heap TID as a tiebreaker attribute, or will have pivot tuples
undergo suffix truncation during a leaf page split (on-disk
compatibility with versions 2 and 3 is preserved). Upgrades to version
4 cannot be performed on-the-fly, unlike upgrades from version 2 to
version 3. contrib/amcheck continues to work with version 2 and 3
indexes, while also enforcing stricter invariants when verifying version
4 indexes. These stricter invariants are the same invariants described
by "3.1.12 Sequencing" from the Lehman and Yao paper.
A later patch will enhance the logic used by nbtree to pick a split
point. This patch is likely to negatively impact performance without
smarter choices around the precise point to split leaf pages at. Making
these two mostly-distinct sets of enhancements into distinct commits
seems like it might clarify their design, even though neither commit is
particularly useful on its own.
The maximum allowed size of new tuples is reduced by an amount equal to
the space required to store an extra MAXALIGN()'d TID in a new high key
during leaf page splits. The user-facing definition of the "1/3 of a
page" restriction is already imprecise, and so does not need to be
revised. However, there should be a compatibility note in the v12
release notes.
Author: Peter Geoghegan
Reviewed-By: Heikki Linnakangas, Alexander Korotkov
Discussion: https://postgr.es/m/CAH2-WzkVb0Kom=R+88fDFb=JSxZMFvbHVC6Mn9LJ2n=X=kS-Uw@mail.gmail.com
2019-03-21 01:04:01 +08:00
|
|
|
4 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | NaN | NaN
|
2013-07-19 02:50:20 +08:00
|
|
|
(1 row)
|
|
|
|
|
|
2011-08-25 12:06:16 +08:00
|
|
|
select pg_relpages('test');
|
|
|
|
|
pg_relpages
|
|
|
|
|
-------------
|
|
|
|
|
0
|
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
|
|
select pg_relpages('test_pkey');
|
|
|
|
|
pg_relpages
|
|
|
|
|
-------------
|
|
|
|
|
1
|
|
|
|
|
(1 row)
|
|
|
|
|
|
2013-07-19 02:50:20 +08:00
|
|
|
select pg_relpages('test_pkey'::text);
|
|
|
|
|
pg_relpages
|
|
|
|
|
-------------
|
|
|
|
|
1
|
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
|
|
select pg_relpages('test_pkey'::name);
|
|
|
|
|
pg_relpages
|
|
|
|
|
-------------
|
|
|
|
|
1
|
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
|
|
select pg_relpages('test_pkey'::regclass);
|
|
|
|
|
pg_relpages
|
|
|
|
|
-------------
|
|
|
|
|
1
|
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
|
|
select pg_relpages(oid) from pg_class where relname = 'test_pkey';
|
|
|
|
|
pg_relpages
|
|
|
|
|
-------------
|
|
|
|
|
1
|
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
|
|
select pg_relpages(relname) from pg_class where relname = 'test_pkey';
|
|
|
|
|
pg_relpages
|
|
|
|
|
-------------
|
|
|
|
|
1
|
|
|
|
|
(1 row)
|
|
|
|
|
|
2012-12-05 15:58:03 +08:00
|
|
|
create index test_ginidx on test using gin (b);
|
|
|
|
|
select * from pgstatginindex('test_ginidx');
|
|
|
|
|
version | pending_pages | pending_tuples
|
|
|
|
|
---------+---------------+----------------
|
2014-01-23 00:51:48 +08:00
|
|
|
2 | 0 | 0
|
2012-12-05 15:58:03 +08:00
|
|
|
(1 row)
|
|
|
|
|
|
2017-02-04 03:35:25 +08:00
|
|
|
create index test_hashidx on test using hash (b);
|
|
|
|
|
select * from pgstathashindex('test_hashidx');
|
2017-04-12 23:53:00 +08:00
|
|
|
version | bucket_pages | overflow_pages | bitmap_pages | unused_pages | live_items | dead_items | free_percent
|
|
|
|
|
---------+--------------+----------------+--------------+--------------+------------+------------+--------------
|
hash: Increase the number of possible overflow bitmaps by 8x.
Per a report from AP, it's not that hard to exhaust the supply of
bitmap pages if you create a table with a hash index and then insert a
few billion rows - and then you start getting errors when you try to
insert additional rows. In the particular case reported by AP,
there's another fix that we can make to improve recycling of overflow
pages, which is another way to avoid the error, but there may be other
cases where this problem happens and that fix won't help. So let's
buy ourselves as much headroom as we can without rearchitecting
anything.
The comments claim that the old limit was 64GB, but it was really
only 32GB, because we didn't use all the bits in the page for bitmap
bits - only the largest power of 2 that could fit after deducting
space for the page header and so forth. Thus, we have 4kB per page
for bitmap bits, not 8kB. The new limit is thus actually 8 times the
old *real* limit but only 4 times the old *purported* limit.
Since this breaks on-disk compatibility, bump HASH_VERSION. We've
already done this earlier in this release cycle, so this doesn't cause
any incremental inconvenience for people using pg_upgrade from
releases prior to v10. However, users who use pg_upgrade to reach
10beta3 or later from 10beta2 or earlier will need to REINDEX any hash
indexes again.
Amit Kapila and Robert Haas
Discussion: http://postgr.es/m/20170704105728.mwb72jebfmok2nm2@zip.com.au
2017-08-05 03:29:26 +08:00
|
|
|
4 | 4 | 0 | 1 | 0 | 0 | 0 | 100
|
2017-02-04 03:35:25 +08:00
|
|
|
(1 row)
|
|
|
|
|
|
2017-03-10 05:34:25 +08:00
|
|
|
-- these should error with the wrong type
|
|
|
|
|
select pgstatginindex('test_pkey');
|
|
|
|
|
ERROR: relation "test_pkey" is not a GIN index
|
|
|
|
|
select pgstathashindex('test_pkey');
|
2018-05-10 00:44:50 +08:00
|
|
|
ERROR: relation "test_pkey" is not a hash index
|
2017-03-10 05:34:25 +08:00
|
|
|
select pgstatindex('test_ginidx');
|
|
|
|
|
ERROR: relation "test_ginidx" is not a btree index
|
|
|
|
|
select pgstathashindex('test_ginidx');
|
2018-05-10 00:44:50 +08:00
|
|
|
ERROR: relation "test_ginidx" is not a hash index
|
2017-03-10 05:34:25 +08:00
|
|
|
select pgstatindex('test_hashidx');
|
|
|
|
|
ERROR: relation "test_hashidx" is not a btree index
|
|
|
|
|
select pgstatginindex('test_hashidx');
|
|
|
|
|
ERROR: relation "test_hashidx" is not a GIN index
|
|
|
|
|
-- check that using any of these functions with unsupported relations will fail
|
|
|
|
|
create table test_partitioned (a int) partition by range (a);
|
2018-05-10 01:03:43 +08:00
|
|
|
create index test_partitioned_index on test_partitioned(a);
|
2017-03-10 05:34:25 +08:00
|
|
|
-- these should all fail
|
|
|
|
|
select pgstattuple('test_partitioned');
|
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 15:38:52 +08:00
|
|
|
ERROR: cannot get tuple-level statistics for relation "test_partitioned"
|
|
|
|
|
DETAIL: This operation is not supported for partitioned tables.
|
2018-05-10 01:03:43 +08:00
|
|
|
select pgstattuple('test_partitioned_index');
|
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 15:38:52 +08:00
|
|
|
ERROR: cannot get tuple-level statistics for relation "test_partitioned_index"
|
|
|
|
|
DETAIL: This operation is not supported for partitioned indexes.
|
2017-03-10 05:34:25 +08:00
|
|
|
select pgstattuple_approx('test_partitioned');
|
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 15:38:52 +08:00
|
|
|
ERROR: relation "test_partitioned" is of wrong relation kind
|
|
|
|
|
DETAIL: This operation is not supported for partitioned tables.
|
2017-03-10 05:34:25 +08:00
|
|
|
select pg_relpages('test_partitioned');
|
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 15:38:52 +08:00
|
|
|
ERROR: cannot get page count of relation "test_partitioned"
|
|
|
|
|
DETAIL: This operation is not supported for partitioned tables.
|
2017-03-10 05:34:25 +08:00
|
|
|
select pgstatindex('test_partitioned');
|
|
|
|
|
ERROR: relation "test_partitioned" is not a btree index
|
|
|
|
|
select pgstatginindex('test_partitioned');
|
|
|
|
|
ERROR: relation "test_partitioned" is not a GIN index
|
|
|
|
|
select pgstathashindex('test_partitioned');
|
|
|
|
|
ERROR: "test_partitioned" is not an index
|
|
|
|
|
create view test_view as select 1;
|
|
|
|
|
-- these should all fail
|
|
|
|
|
select pgstattuple('test_view');
|
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 15:38:52 +08:00
|
|
|
ERROR: cannot get tuple-level statistics for relation "test_view"
|
|
|
|
|
DETAIL: This operation is not supported for views.
|
2017-03-10 05:34:25 +08:00
|
|
|
select pgstattuple_approx('test_view');
|
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 15:38:52 +08:00
|
|
|
ERROR: relation "test_view" is of wrong relation kind
|
|
|
|
|
DETAIL: This operation is not supported for views.
|
2017-03-10 05:34:25 +08:00
|
|
|
select pg_relpages('test_view');
|
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 15:38:52 +08:00
|
|
|
ERROR: cannot get page count of relation "test_view"
|
|
|
|
|
DETAIL: This operation is not supported for views.
|
2017-03-10 05:34:25 +08:00
|
|
|
select pgstatindex('test_view');
|
|
|
|
|
ERROR: relation "test_view" is not a btree index
|
|
|
|
|
select pgstatginindex('test_view');
|
|
|
|
|
ERROR: relation "test_view" is not a GIN index
|
|
|
|
|
select pgstathashindex('test_view');
|
|
|
|
|
ERROR: "test_view" is not an index
|
|
|
|
|
create foreign data wrapper dummy;
|
|
|
|
|
create server dummy_server foreign data wrapper dummy;
|
|
|
|
|
create foreign table test_foreign_table () server dummy_server;
|
|
|
|
|
-- these should all fail
|
|
|
|
|
select pgstattuple('test_foreign_table');
|
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 15:38:52 +08:00
|
|
|
ERROR: cannot get tuple-level statistics for relation "test_foreign_table"
|
|
|
|
|
DETAIL: This operation is not supported for foreign tables.
|
2017-03-10 05:34:25 +08:00
|
|
|
select pgstattuple_approx('test_foreign_table');
|
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 15:38:52 +08:00
|
|
|
ERROR: relation "test_foreign_table" is of wrong relation kind
|
|
|
|
|
DETAIL: This operation is not supported for foreign tables.
|
2017-03-10 05:34:25 +08:00
|
|
|
select pg_relpages('test_foreign_table');
|
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 15:38:52 +08:00
|
|
|
ERROR: cannot get page count of relation "test_foreign_table"
|
|
|
|
|
DETAIL: This operation is not supported for foreign tables.
|
2017-03-10 05:34:25 +08:00
|
|
|
select pgstatindex('test_foreign_table');
|
|
|
|
|
ERROR: relation "test_foreign_table" is not a btree index
|
|
|
|
|
select pgstatginindex('test_foreign_table');
|
|
|
|
|
ERROR: relation "test_foreign_table" is not a GIN index
|
|
|
|
|
select pgstathashindex('test_foreign_table');
|
|
|
|
|
ERROR: "test_foreign_table" is not an index
|
|
|
|
|
-- a partition of a partitioned table should work though
|
|
|
|
|
create table test_partition partition of test_partitioned for values from (1) to (100);
|
|
|
|
|
select pgstattuple('test_partition');
|
|
|
|
|
pgstattuple
|
|
|
|
|
---------------------
|
|
|
|
|
(0,0,0,0,0,0,0,0,0)
|
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
|
|
select pgstattuple_approx('test_partition');
|
|
|
|
|
pgstattuple_approx
|
|
|
|
|
-----------------------
|
|
|
|
|
(0,0,0,0,0,0,0,0,0,0)
|
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
|
|
select pg_relpages('test_partition');
|
|
|
|
|
pg_relpages
|
|
|
|
|
-------------
|
|
|
|
|
0
|
|
|
|
|
(1 row)
|
|
|
|
|
|
2020-06-30 06:29:35 +08:00
|
|
|
-- toast tables should work
|
|
|
|
|
select pgstattuple((select reltoastrelid from pg_class where relname = 'test'));
|
|
|
|
|
pgstattuple
|
|
|
|
|
---------------------
|
|
|
|
|
(0,0,0,0,0,0,0,0,0)
|
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
|
|
select pgstattuple_approx((select reltoastrelid from pg_class where relname = 'test'));
|
|
|
|
|
pgstattuple_approx
|
|
|
|
|
-----------------------
|
|
|
|
|
(0,0,0,0,0,0,0,0,0,0)
|
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
|
|
select pg_relpages((select reltoastrelid from pg_class where relname = 'test'));
|
|
|
|
|
pg_relpages
|
|
|
|
|
-------------
|
|
|
|
|
0
|
|
|
|
|
(1 row)
|
|
|
|
|
|
2017-03-10 05:34:25 +08:00
|
|
|
-- not for the index calls though, of course
|
|
|
|
|
select pgstatindex('test_partition');
|
|
|
|
|
ERROR: relation "test_partition" is not a btree index
|
|
|
|
|
select pgstatginindex('test_partition');
|
|
|
|
|
ERROR: relation "test_partition" is not a GIN index
|
|
|
|
|
select pgstathashindex('test_partition');
|
|
|
|
|
ERROR: "test_partition" is not an index
|
2017-03-10 09:06:11 +08:00
|
|
|
-- an actual index of a partitioned table should work though
|
2017-03-10 05:34:25 +08:00
|
|
|
create index test_partition_idx on test_partition(a);
|
|
|
|
|
create index test_partition_hash_idx on test_partition using hash (a);
|
|
|
|
|
-- these should work
|
|
|
|
|
select pgstatindex('test_partition_idx');
|
|
|
|
|
pgstatindex
|
|
|
|
|
------------------------------
|
Make heap TID a tiebreaker nbtree index column.
Make nbtree treat all index tuples as having a heap TID attribute.
Index searches can distinguish duplicates by heap TID, since heap TID is
always guaranteed to be unique. This general approach has numerous
benefits for performance, and is prerequisite to teaching VACUUM to
perform "retail index tuple deletion".
Naively adding a new attribute to every pivot tuple has unacceptable
overhead (it bloats internal pages), so suffix truncation of pivot
tuples is added. This will usually truncate away the "extra" heap TID
attribute from pivot tuples during a leaf page split, and may also
truncate away additional user attributes. This can increase fan-out,
especially in a multi-column index. Truncation can only occur at the
attribute granularity, which isn't particularly effective, but works
well enough for now. A future patch may add support for truncating
"within" text attributes by generating truncated key values using new
opclass infrastructure.
Only new indexes (BTREE_VERSION 4 indexes) will have insertions that
treat heap TID as a tiebreaker attribute, or will have pivot tuples
undergo suffix truncation during a leaf page split (on-disk
compatibility with versions 2 and 3 is preserved). Upgrades to version
4 cannot be performed on-the-fly, unlike upgrades from version 2 to
version 3. contrib/amcheck continues to work with version 2 and 3
indexes, while also enforcing stricter invariants when verifying version
4 indexes. These stricter invariants are the same invariants described
by "3.1.12 Sequencing" from the Lehman and Yao paper.
A later patch will enhance the logic used by nbtree to pick a split
point. This patch is likely to negatively impact performance without
smarter choices around the precise point to split leaf pages at. Making
these two mostly-distinct sets of enhancements into distinct commits
seems like it might clarify their design, even though neither commit is
particularly useful on its own.
The maximum allowed size of new tuples is reduced by an amount equal to
the space required to store an extra MAXALIGN()'d TID in a new high key
during leaf page splits. The user-facing definition of the "1/3 of a
page" restriction is already imprecise, and so does not need to be
revised. However, there should be a compatibility note in the v12
release notes.
Author: Peter Geoghegan
Reviewed-By: Heikki Linnakangas, Alexander Korotkov
Discussion: https://postgr.es/m/CAH2-WzkVb0Kom=R+88fDFb=JSxZMFvbHVC6Mn9LJ2n=X=kS-Uw@mail.gmail.com
2019-03-21 01:04:01 +08:00
|
|
|
(4,0,8192,0,0,0,0,0,NaN,NaN)
|
2017-03-10 05:34:25 +08:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
|
|
select pgstathashindex('test_partition_hash_idx');
|
|
|
|
|
pgstathashindex
|
|
|
|
|
---------------------
|
hash: Increase the number of possible overflow bitmaps by 8x.
Per a report from AP, it's not that hard to exhaust the supply of
bitmap pages if you create a table with a hash index and then insert a
few billion rows - and then you start getting errors when you try to
insert additional rows. In the particular case reported by AP,
there's another fix that we can make to improve recycling of overflow
pages, which is another way to avoid the error, but there may be other
cases where this problem happens and that fix won't help. So let's
buy ourselves as much headroom as we can without rearchitecting
anything.
The comments claim that the old limit was 64GB, but it was really
only 32GB, because we didn't use all the bits in the page for bitmap
bits - only the largest power of 2 that could fit after deducting
space for the page header and so forth. Thus, we have 4kB per page
for bitmap bits, not 8kB. The new limit is thus actually 8 times the
old *real* limit but only 4 times the old *purported* limit.
Since this breaks on-disk compatibility, bump HASH_VERSION. We've
already done this earlier in this release cycle, so this doesn't cause
any incremental inconvenience for people using pg_upgrade from
releases prior to v10. However, users who use pg_upgrade to reach
10beta3 or later from 10beta2 or earlier will need to REINDEX any hash
indexes again.
Amit Kapila and Robert Haas
Discussion: http://postgr.es/m/20170704105728.mwb72jebfmok2nm2@zip.com.au
2017-08-05 03:29:26 +08:00
|
|
|
(4,8,0,1,0,0,0,100)
|
2017-03-10 05:34:25 +08:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
|
|
drop table test_partitioned;
|
|
|
|
|
drop view test_view;
|
|
|
|
|
drop foreign table test_foreign_table;
|
|
|
|
|
drop server dummy_server;
|
|
|
|
|
drop foreign data wrapper dummy;
|
