-
Notifications
You must be signed in to change notification settings - Fork 69
Description
Описание проблемы
Добрый день. В указанной конфигурации после применения pg_repack на секционированную таблицу данные "возвращаются" в родительскую таблицу. Ситуация выглядит очень странно, описываю путь воспроизведения ниже.
- Подготовка
CREATE TABLE my_table ( key integer CONSTRAINT key PRIMARY KEY ); INSERT INTO my_table (SELECT generate_series(1, 1000000)); SELECT create_hash_partitions('my_table', 'key', 10); create_hash_partitions ------------------------ 10 (1 строка)
- Удостоверимся, что данные лежат только в партициях:
SELECT COUNT(*) FROM my_table; count --------- 1000000 (1 строка) SELECT COUNT(*) FROM ONLY my_table; count ------- 0 (1 строка)
- Прогоняем pg_repack:
$ pg_repack -t my_schema.my_table
INFO: repacking table "my_schema.my_table"- Смотрим count() еще раз:
SELECT COUNT(*) FROM my_table; count --------- 1000000 (1 строка) SELECT COUNT(*) FROM ONLY my_table; count --------- 1000000 (1 строка)
Проблема в последнем COUNT(). Откуда в родительской таблице записи? Причем они есть и в партициях тоже:
SELECT COUNT(*) FROM ONLY my_table_0; count -------- 100088 (1 строка) SELECT COUNT(*) FROM ONLY my_table_1; count ------- 99715 (1 строка) SELECT COUNT(*) FROM ONLY my_table_3; count ------- 99909 (1 строка)
Ну т.е. если бы они РЕАЛЬНО были бы в родительской таблице, то COUNT(*) без ONLY должен был бы показать в 2 раза больше строк, но он показывает ровно 1000000.
Вот EXPLAIN:
EXPLAIN ANALYZE SELECT COUNT(*) FROM ONLY my_table; QUERY PLAN ------------------------------------------------------------------------------------------------------------------------- Aggregate (cost=16925.00..16925.01 rows=1 width=8) (actual time=110.382..110.382 rows=1 loops=1) -> Seq Scan on my_table (cost=0.00..14425.00 rows=1000000 width=0) (actual time=0.008..59.636 rows=1000000 loops=1) Planning time: 0.044 ms Execution time: 110.402 ms (4 строки)
Пробовал делать то же самое в следующих вариациях:
а) таблица с ranged-секционированием по дате;
б) перед прогоном pg_repack добавлял SELECT set_enable_parent('my_table', FALSE);
в) pg_repack с опцией -I my_schema.my_table (чтобы он взял и все дочерние таблицы)
Результат тот же. Помогите, пожалуйста, разобраться. Может быть я что-то не учитываю? Спасибо!
Environment
SELECT * FROM pg_extension; extname | extowner | extnamespace | extrelocatable | extversion | extconfig | extcondition ---------------+----------+--------------+----------------+------------+-----------------+-------------- plpgsql | 10 | 11 | f | 1.0 | | btree_gin | 10 | 2200 | t | 1.0 | | fuzzystrmatch | 10 | 267783 | t | 1.1 | | intarray | 10 | 2200 | t | 1.2 | | pgstattuple | 10 | 2200 | t | 1.4 | | postgres_fdw | 10 | 267783 | t | 1.0 | | btree_gist | 10 | 2200 | t | 1.2 | | pg_trgm | 10 | 2200 | t | 1.3 | | pg_pathman | 10 | 2200 | f | 1.4 | {333661,333672} | {"",""} hstore | 10 | 2200 | t | 1.4 | | pg_repack | 10 | 2200 | f | 1.4.2 | | (11 строк) SELECT version(); version ---------------------------------------------------------------------------------------------------------- PostgreSQL 9.6.4 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18), 64-bit (1 строка) SELECT get_pathman_lib_version(); get_pathman_lib_version ------------------------- 10407 (1 строка)