2011-08-25 06:06:16 +02: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 08:58:03 +01:00
|
|
|
create table test (a int primary key, b int[]);
|
2013-07-18 20:50:20 +02: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 06:06:16 +02: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-18 20:50:20 +02: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 06:06:16 +02: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-18 20:50:20 +02: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-18 21:40:35 +01: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 06:06:16 +02:00
|
|
|
version | tree_level | index_size | root_block_no | internal_pages | leaf_pages | empty_pages | deleted_pages | avg_leaf_density | leaf_fragmentation
|
|
|
|
---------+------------+------------+---------------+----------------+------------+-------------+---------------+------------------+--------------------
|
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-18 21:40:35 +01:00
|
|
|
2 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | NaN | NaN
|
2011-08-25 06:06:16 +02: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-18 21:40:35 +01: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-18 20:50:20 +02:00
|
|
|
version | tree_level | index_size | root_block_no | internal_pages | leaf_pages | empty_pages | deleted_pages | avg_leaf_density | leaf_fragmentation
|
|
|
|
---------+------------+------------+---------------+----------------+------------+-------------+---------------+------------------+--------------------
|
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-18 21:40:35 +01:00
|
|
|
2 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | NaN | NaN
|
2013-07-18 20:50:20 +02: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-18 21:40:35 +01: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-18 20:50:20 +02:00
|
|
|
version | tree_level | index_size | root_block_no | internal_pages | leaf_pages | empty_pages | deleted_pages | avg_leaf_density | leaf_fragmentation
|
|
|
|
---------+------------+------------+---------------+----------------+------------+-------------+---------------+------------------+--------------------
|
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-18 21:40:35 +01:00
|
|
|
2 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | NaN | NaN
|
2013-07-18 20:50:20 +02: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-18 21:40:35 +01: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-18 20:50:20 +02:00
|
|
|
version | tree_level | index_size | root_block_no | internal_pages | leaf_pages | empty_pages | deleted_pages | avg_leaf_density | leaf_fragmentation
|
|
|
|
---------+------------+------------+---------------+----------------+------------+-------------+---------------+------------------+--------------------
|
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-18 21:40:35 +01:00
|
|
|
2 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | NaN | NaN
|
2013-07-18 20:50:20 +02:00
|
|
|
(1 row)
|
|
|
|
|
2011-08-25 06:06:16 +02:00
|
|
|
select pg_relpages('test');
|
|
|
|
pg_relpages
|
|
|
|
-------------
|
|
|
|
0
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select pg_relpages('test_pkey');
|
|
|
|
pg_relpages
|
|
|
|
-------------
|
|
|
|
1
|
|
|
|
(1 row)
|
|
|
|
|
2013-07-18 20:50:20 +02: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 08:58:03 +01:00
|
|
|
create index test_ginidx on test using gin (b);
|
|
|
|
select * from pgstatginindex('test_ginidx');
|
|
|
|
version | pending_pages | pending_tuples
|
|
|
|
---------+---------------+----------------
|
2014-01-22 17:51:48 +01:00
|
|
|
2 | 0 | 0
|
2012-12-05 08:58:03 +01:00
|
|
|
(1 row)
|
|
|
|
|
2017-02-03 20:35:25 +01:00
|
|
|
create index test_hashidx on test using hash (b);
|
|
|
|
select * from pgstathashindex('test_hashidx');
|
|
|
|
version | bucket_pages | overflow_pages | bitmap_pages | zero_pages | live_items | dead_items | free_percent
|
|
|
|
---------+--------------+----------------+--------------+------------+------------+------------+--------------
|
Expand hash indexes more gradually.
Since hash indexes typically have very few overflow pages, adding a
new splitpoint essentially doubles the on-disk size of the index,
which can lead to large and abrupt increases in disk usage (and
perhaps long delays on occasion). To mitigate this problem to some
degree, divide larger splitpoints into four equal phases. This means
that, for example, instead of growing from 4GB to 8GB all at once, a
hash index will now grow from 4GB to 5GB to 6GB to 7GB to 8GB, which
is perhaps still not as smooth as we'd like but certainly an
improvement.
This changes the on-disk format of the metapage, so bump HASH_VERSION
from 2 to 3. This will force a REINDEX of all existing hash indexes,
but that's probably a good idea anyway. First, hash indexes from
pre-10 versions of PostgreSQL could easily be corrupted, and we don't
want to confuse corruption carried over from an older release with any
corruption caused despite the new write-ahead logging in v10. Second,
it will let us remove some backward-compatibility code added by commit
293e24e507838733aba4748b514536af2d39d7f2.
Mithun Cy, reviewed by Amit Kapila, Jesper Pedersen and me. Regression
test outputs updated by me.
Discussion: http://postgr.es/m/CAD__OuhG6F1gQLCgMQNnMNgoCvOLQZz9zKYJQNYvYmmJoM42gA@mail.gmail.com
Discussion: http://postgr.es/m/CA+TgmoYty0jCf-pa+m+vYUJ716+AxM7nv_syvyanyf5O-L_i2A@mail.gmail.com
2017-04-04 05:46:33 +02:00
|
|
|
3 | 4 | 0 | 1 | 0 | 0 | 0 | 100
|
2017-02-03 20:35:25 +01:00
|
|
|
(1 row)
|
|
|
|
|
2017-03-09 22:34:25 +01: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');
|
|
|
|
ERROR: relation "test_pkey" is not a HASH index
|
|
|
|
select pgstatindex('test_ginidx');
|
|
|
|
ERROR: relation "test_ginidx" is not a btree index
|
|
|
|
select pgstathashindex('test_ginidx');
|
|
|
|
ERROR: relation "test_ginidx" is not a HASH index
|
|
|
|
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);
|
|
|
|
-- these should all fail
|
|
|
|
select pgstattuple('test_partitioned');
|
|
|
|
ERROR: "test_partitioned" (partitioned table) is not supported
|
|
|
|
select pgstattuple_approx('test_partitioned');
|
|
|
|
ERROR: "test_partitioned" is not a table or materialized view
|
|
|
|
select pg_relpages('test_partitioned');
|
|
|
|
ERROR: "test_partitioned" is not a table, index, materialized view, sequence, or TOAST table
|
|
|
|
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');
|
|
|
|
ERROR: "test_view" (view) is not supported
|
|
|
|
select pgstattuple_approx('test_view');
|
|
|
|
ERROR: "test_view" is not a table or materialized view
|
|
|
|
select pg_relpages('test_view');
|
|
|
|
ERROR: "test_view" is not a table, index, materialized view, sequence, or TOAST table
|
|
|
|
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');
|
|
|
|
ERROR: "test_foreign_table" (foreign table) is not supported
|
|
|
|
select pgstattuple_approx('test_foreign_table');
|
|
|
|
ERROR: "test_foreign_table" is not a table or materialized view
|
|
|
|
select pg_relpages('test_foreign_table');
|
|
|
|
ERROR: "test_foreign_table" is not a table, index, materialized view, sequence, or TOAST table
|
|
|
|
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)
|
|
|
|
|
|
|
|
-- 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 02:06:11 +01:00
|
|
|
-- an actual index of a partitioned table should work though
|
2017-03-09 22:34:25 +01: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
|
|
|
|
------------------------------
|
|
|
|
(2,0,8192,0,0,0,0,0,NaN,NaN)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select pgstathashindex('test_partition_hash_idx');
|
|
|
|
pgstathashindex
|
|
|
|
---------------------
|
Expand hash indexes more gradually.
Since hash indexes typically have very few overflow pages, adding a
new splitpoint essentially doubles the on-disk size of the index,
which can lead to large and abrupt increases in disk usage (and
perhaps long delays on occasion). To mitigate this problem to some
degree, divide larger splitpoints into four equal phases. This means
that, for example, instead of growing from 4GB to 8GB all at once, a
hash index will now grow from 4GB to 5GB to 6GB to 7GB to 8GB, which
is perhaps still not as smooth as we'd like but certainly an
improvement.
This changes the on-disk format of the metapage, so bump HASH_VERSION
from 2 to 3. This will force a REINDEX of all existing hash indexes,
but that's probably a good idea anyway. First, hash indexes from
pre-10 versions of PostgreSQL could easily be corrupted, and we don't
want to confuse corruption carried over from an older release with any
corruption caused despite the new write-ahead logging in v10. Second,
it will let us remove some backward-compatibility code added by commit
293e24e507838733aba4748b514536af2d39d7f2.
Mithun Cy, reviewed by Amit Kapila, Jesper Pedersen and me. Regression
test outputs updated by me.
Discussion: http://postgr.es/m/CAD__OuhG6F1gQLCgMQNnMNgoCvOLQZz9zKYJQNYvYmmJoM42gA@mail.gmail.com
Discussion: http://postgr.es/m/CA+TgmoYty0jCf-pa+m+vYUJ716+AxM7nv_syvyanyf5O-L_i2A@mail.gmail.com
2017-04-04 05:46:33 +02:00
|
|
|
(3,8,0,1,0,0,0,100)
|
2017-03-09 22:34:25 +01: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;
|