Postgres Partition by Character Prefix

Question

Good Day,

Я хотел бы проверить, как лучше всего разбить таблицу Postgres на префикс столбцов. У меня есть большой стол (+ - 750 миллионов строк х 10 столбцов), и я хотел бы разделить его на префикс столбца 1. данных выглядит как:

ABCDEF1xxxxxxxx 
ABCDEF1xxxxxxxy 
ABCDEF1xxxxxxxz 
ABCDEF2xxxxxxxx 
ABCDEF2xxxxxxxy 
ABCDEF2xxxxxxxz 
ABCDEF3xxxxxxxx 
ABCDEF3xxxxxxxz 
ABCDEF4xxxxxxxx 
ABCDEF4xxxxxxxy 

Их будет только когда-либо 10 перегородки т.е. ABCDEF0 ...-> ABCDEF9 ...

то, что я в настоящее время сделать, это сделать таблицы, как:

CREATE TABLE public.mydata_ABCDEF1 (
CHECK (col1 like 'ABCDEF1%') 
) INHERITS (public.mydata); 

CREATE TABLE public.mydata_ABCDEF2 (
CHECK (col1 like 'ABCDEF2%') 
) INHERITS (public.mydata); 

и т.д. Тогда триггер с подобной логикой:

IF (NEW.col1 like 'ABCDEF1%') THEN 
    INSERT INTO public.mydata_ABCDEF1 VALUES (NEW.*); 
ELSIF (NEW.imsi like 'ABCDEF2%') THEN 
    INSERT INTO public.simdata_ABCDEF2 VALUES (NEW.*); 

Я обеспокоен тем, что разделение таким образом ускорит время запроса? или если я должен рассмотреть раздел на substr (не уверен, как), или если я должен создать новый столбец с префиксом и разделом в этом столбце?

Любые советы приветствуются.

Answer 1

Это позволит значительно ускорить ваши запросы, когда каждый из секционированных таблиц имеют свои индексы распределяли, как надлежащим образом, например:

CREATE INDEX ON public.mydata_ABCDEF1 (...) WHERE col1 like 'ABCDEF1%'; 

Answer 2

Короткий ответ «скорее всего нет», но это действительно зависит от того, какие ваши запросы.

Вопрос в том, что вы пытаетесь выполнить с разделением? Вообще говоря, индекс btree PostgreSQL очень быстр и эффективен при поиске конкретных записей, которые вы запрашиваете, - быстрее, чем PostgreSQL при определении того, какая таблица из набора секционированных таблиц содержит ваши данные.

В тех случаях, чрезвычайно полезно, когда это помогает в управлении данными. Причина в том, что полезно, что вы часто можете разбивать на основе времени, а затем, когда данные устаревают достаточно долго, просто удалите старое разделение вместо того, чтобы выдавать запросы «DELETE», которые отмечают записи как удаленные, которые затем должны быть VACUUM'd, чтобы освободить место, и заканчивается тем, что вызывает раздувание в таблице и индексы.

Записи 300M - это точка, где я мог бы рассмотреть возможность разбиения на разделы, но я бы не стал переходить к разделению данных в этой точке без ясной причины, по которой полезно будет разделять данные.

Также имейте в виду, что планировщик запросов PostgreSQL не очень хорошо обрабатывает очень большое количество разделов; сотни и тысячи разделов замедлят время планирования. Это не очень очевидно, с предварительно 9,5 версии, но в 9,5 «EXPLAIN ANALYZE» возвращает время планирования, необходимое для данного запроса:

=*> explain analyze select * from downloads; 
                 QUERY PLAN          
------------------------------------------------------------------------------------------------------- 
Seq Scan on downloads (cost=0.00..38591.76 rows=999976 width=193) (actual time=23.863..2088.732 rows= 
Planning time: 0.219 ms 
Execution time: 2552.878 ms 
(3 rows)