PostgreSQL. Индексы и партицирование

Question

[Юрий]

Доброго времени суток, хабраюзеры!

Столкнулся с непонятным для меня явлением в моей любимой СУБД — PostgreSQL.

Суть такова. Имеются две таблицы с одинаковыми данными. Первая — обычная, вторая — партицированная по автоинкрементному индексу (каждая партиция содержит 5 млн записей). Этот же индекс является primary key в обоих таблицах. Проблема в том, что запросы, связанные с сортировкой по этому primary key, в партицированной таблице выполняются неприлично долго. Например (индекс традиционно назван id):
1) на обычной таблице:

explain analyze (select * from my_data order by id desc limit 10);
                                    QUERY PLAN
------------------------------------------------------------------------------------------------------

Limit (cost=0.00..7.26 rows=10 width=418) (actual time=0.012..26.831 rows=10 loops=1)
  -> Index Scan Backward using my_data_pkey on my_data (cost=0.00..20081200.21 rows=27676900 width=418) (actual time=0.010..26.809 rows=10 loops=1)
Total runtime: 26.864 ms
(3 rows)

* This source code was highlighted with Source Code Highlighter.

2) на партицированной таблице:

explain analyze (select * from my_data_master order by id desc limit 10);
                                       QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=2189687.00..2189687.02 rows=10 width=100) (actual time=314882.294..314882.314 rows=10 loops=1)
  -> Sort (cost=2189687.00..2305298.08 rows=46244433 width=100) (actual time=314882.292..314882.301 rows=10 loops=1)
     Sort Key: public.my_data_master.id
     Sort Method: top-N heapsort Memory: 26kB
     -> Result (cost=0.00..1190361.43 rows=46244433 width=100) (actual time=209.347..250605.224 rows=46495464 loops=1)
        -> Append (cost=0.00..1190361.43 rows=46244433 width=100) (actual time=209.343..168812.754 rows=46495464 loops=1)
           -> Seq Scan on my_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
           -> Seq Scan on my_data_5mln my_data_master (cost=0.00..0.00 rows=1 width=98) (actual time=0.002..0.002 rows=0 loops=1)
           -> Seq Scan on my_data_10mln my_data_master (cost=0.00..0.00 rows=1 width=99) (actual time=0.001..0.001 rows=0 loops=1)
           -> Seq Scan on my_data_15mln my_data_master (cost=0.00..0.00 rows=1 width=99) (actual time=0.001..0.001 rows=0 loops=1)
           -> Seq Scan on my_data_20mln my_data_master (cost=0.00..0.00 rows=1 width=98) (actual time=0.001..0.001 rows=0 loops=1)
           -> Seq Scan on my_data_25mln my_data_master (cost=0.00..0.00 rows=1 width=99) (actual time=0.001..0.001 rows=0 loops=1)
           -> Seq Scan on my_data_30mln my_data_master (cost=0.00..81068.66 rows=1934658 width=100) (actual time=209.329..7484.434 rows=1934658 loops=1)
           -> Seq Scan on my_data_35mln my_data_master (cost=0.00..85868.90 rows=126902 width=100) (actual time=9.837..7667.541 rows=247612 loops=1)
           -> Seq Scan on my_data_40mln my_data_master (cost=0.00..85877.48 rows=54482 width=100) (actual time=11.843..8542.494 rows=107813 loops=1)
           -> Seq Scan on my_data_45mln my_data_master (cost=0.00..85970.71 rows=82715 width=101) (actual time=16.713..8438.728 rows=162790 loops=1)
           -> Seq Scan on my_data_50mln my_data_master (cost=0.00..114586.52 rows=3532521 width=100) (actual time=12.295..9758.697 rows=3532521 loops=1)
           -> Seq Scan on my_data_55mln my_data_master (cost=0.00..90983.00 rows=5000000 width=100) (actual time=19.895..6268.184 rows=5000000 loops=1)
           -> Seq Scan on my_data_60mln my_data_master (cost=0.00..90966.00 rows=5000000 width=100) (actual time=14.538..6459.220 rows=5000000 loops=1)
           -> Seq Scan on my_data_65mln my_data_master (cost=0.00..90746.00 rows=5000000 width=100) (actual time=9.685..6464.820 rows=5000000 loops=1)
           -> Seq Scan on my_data_70mln my_data_master (cost=0.00..90985.00 rows=5000000 width=100) (actual time=11.304..6468.359 rows=5000000 loops=1)
           -> Seq Scan on my_data_75mln my_data_master (cost=0.00..90958.00 rows=5000000 width=100) (actual time=17.406..6389.408 rows=5000000 loops=1)
           -> Seq Scan on my_data_80mln my_data_master (cost=0.00..90970.00 rows=5000000 width=99) (actual time=13.072..6537.780 rows=5000000 loops=1)
           -> Seq Scan on my_data_85mln my_data_master (cost=0.00..90950.00 rows=5000000 width=99) (actual time=8.716..6582.697 rows=5000000 loops=1)
           -> Seq Scan on my_data_90mln my_data_master (cost=0.00..90934.00 rows=5000000 width=99) (actual time=11.954..6799.891 rows=5000000 loops=1)
           -> Seq Scan on my_data_95mln my_data_master (cost=0.00..9274.07 rows=510070 width=100) (actual time=7.106..640.611 rows=510070 loops=1)
           -> Seq Scan on my_data_100mln my_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.003..0.003 rows=0 loops=1)
           -> Seq Scan on my_data_105mln my_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
           -> Seq Scan on my_data_110mln my_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
           -> Seq Scan on my_data_115mln my_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
           -> Seq Scan on my_data_120mln my_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.000..0.000 rows=0 loops=1)
           -> Seq Scan on my_data_125mln my_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
           -> Seq Scan on my_data_130mln my_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
           -> Seq Scan on my_data_135mln my_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
           -> Seq Scan on my_data_140mln my_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
           -> Seq Scan on my_data_145mln my_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
           -> Seq Scan on my_data_150mln my_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
           -> Seq Scan on my_data_155mln my_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
           -> Seq Scan on my_data_160mln my_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
           -> Seq Scan on my_data_165mln my_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
           -> Seq Scan on my_data_170mln my_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
           -> Seq Scan on my_data_175mln my_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
           -> Seq Scan on my_data_180mln my_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
           -> Seq Scan on my_data_185mln my_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
           -> Seq Scan on my_data_190mln my_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
           -> Seq Scan on my_data_195mln my_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
           -> Seq Scan on my_data_200mln my_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
Total runtime: 314882.697 ms
(48 rows)

* This source code was highlighted with Source Code Highlighter.

Такая же история с запросом типа:

select max(id) from my_data_master;
                                    

* This source code was highlighted with Source Code Highlighter.

Подскажите, гуру, есть какая-либо хитрость в индексах для партицированных таблиц?

Answer 1

[galaxy]

Хмм… а исключающие чеки у вас есть на дочерних таблицах (т.е. alter table cdr_data_90mln add constraint cc_cdr_data_90mln check (id >= 90000000 and id < 95000000) )?

Comments

[galaxy]

Вот, кстати, пример почти по мануалу:

CREATE TABLE data (
    id bigserial,
    something text,
    primary key (id)
);

CREATE TABLE data_id1m (CHECK ( id < 1000000 ), primary key (id)) INHERITS (data);
CREATE TABLE data_id2m (CHECK ( id >= 1000000 AND id < 2000000 ), primary key (id)) INHERITS (data);
CREATE TABLE data_id3m (CHECK ( id >= 2000000 AND id < 3000000 ), primary key (id)) INHERITS (data);
CREATE TABLE data_id4m (CHECK ( id >= 3000000 AND id < 4000000 ), primary key (id)) INHERITS (data);
CREATE TABLE data_id5m (CHECK ( id >= 4000000 AND id < 5000000 ), primary key (id)) INHERITS (data);

CREATE OR REPLACE FUNCTION data_insert_trigger()
RETURNS TRIGGER AS $$
BEGIN
    IF ( NEW.id < 1000000 ) THEN
        INSERT INTO data_id1m VALUES (NEW.*);
    ELSIF ( NEW.id >= 1000000 AND NEW.id < 2000000  ) THEN
        INSERT INTO data_id2m VALUES (NEW.*);
    ELSIF ( NEW.id >= 2000000 AND NEW.id < 3000000  ) THEN
        INSERT INTO data_id3m VALUES (NEW.*);
    ELSIF ( NEW.id >= 3000000 AND NEW.id < 4000000  ) THEN
        INSERT INTO data_id4m VALUES (NEW.*);
    ELSIF ( NEW.id >= 4000000 AND NEW.id < 5000000  ) THEN
        INSERT INTO data_id5m VALUES (NEW.*);
    ELSE
        RAISE EXCEPTION 'Date out of range.  Fix the data_insert_trigger() function!';
    END IF;
    RETURN NULL;
END;
$$
LANGUAGE plpgsql;


CREATE TRIGGER insert_data_trigger
    BEFORE INSERT ON data
    FOR EACH ROW EXECUTE PROCEDURE data_insert_trigger();
	
insert into data (something)
select repeat(i::text, 20) from generate_series(1, 4500000) i;

test=# explain analyze select * from data order by id desc limit 10;
                                                                              QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=0.08..0.84 rows=10 width=146) (actual time=18.751..18.817 rows=10 loops=1)
   ->  Result  (cost=0.08..341945.50 rows=4504501 width=146) (actual time=18.748..18.796 rows=10 loops=1)
         ->  Merge Append  (cost=0.08..341945.50 rows=4504501 width=146) (actual time=18.746..18.777 rows=10 loops=1)
               Sort Key: public.data.id
               ->  Index Scan Backward using data_pkey on data  (cost=0.00..8.27 rows=1 width=40) (actual time=0.005..0.005 rows=0 loops=1)
               ->  Index Scan Backward using data_id1m_pkey on data_id1m data  (cost=0.00..45302.34 rows=999999 width=126) (actual time=5.790..5.790 rows=1 loops=1)
               ->  Index Scan Backward using data_id2m_pkey on data_id2m data  (cost=0.00..48194.36 rows=1000000 width=151) (actual time=7.983..7.983 rows=1 loops=1)
               ->  Index Scan Backward using data_id3m_pkey on data_id3m data  (cost=0.00..48206.36 rows=1000000 width=152) (actual time=0.009..0.009 rows=1 loops=1)
               ->  Index Scan Backward using data_id4m_pkey on data_id4m data  (cost=0.00..48206.36 rows=1000000 width=152) (actual time=4.934..4.934 rows=1 loops=1)
               ->  Index Scan Backward using data_id5m_pkey on data_id5m data  (cost=0.00..24326.82 rows=504501 width=152) (actual time=0.014..0.025 rows=10 loops=1)
 Total runtime: 18.878 ms
(11 rows)


test=# explain analyze select max(id) from data;
                                                                               QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Result  (cost=0.16..0.17 rows=1 width=0) (actual time=136.437..136.438 rows=1 loops=1)
   InitPlan 1 (returns $0)
     ->  Limit  (cost=0.08..0.16 rows=1 width=8) (actual time=136.425..136.426 rows=1 loops=1)
           ->  Merge Append  (cost=0.08..353206.75 rows=4504501 width=8) (actual time=136.422..136.422 rows=1 loops=1)
                 Sort Key: public.data.id
                 ->  Index Scan Backward using data_pkey on data  (cost=0.00..8.27 rows=1 width=8) (actual time=7.295..7.295 rows=0 loops=1)
                       Index Cond: (id IS NOT NULL)
                 ->  Index Scan Backward using data_id1m_pkey on data_id1m data  (cost=0.00..47802.34 rows=999999 width=8) (actual time=45.417..45.417 rows=1 loops=1)
                       Index Cond: (id IS NOT NULL)
                 ->  Index Scan Backward using data_id2m_pkey on data_id2m data  (cost=0.00..50694.36 rows=1000000 width=8) (actual time=40.746..40.746 rows=1 loops=1)
                       Index Cond: (id IS NOT NULL)
                 ->  Index Scan Backward using data_id3m_pkey on data_id3m data  (cost=0.00..50706.36 rows=1000000 width=8) (actual time=21.661..21.661 rows=1 loops=1)
                       Index Cond: (id IS NOT NULL)
                 ->  Index Scan Backward using data_id4m_pkey on data_id4m data  (cost=0.00..50706.36 rows=1000000 width=8) (actual time=21.018..21.018 rows=1 loops=1)
                       Index Cond: (id IS NOT NULL)
                 ->  Index Scan Backward using data_id5m_pkey on data_id5m data  (cost=0.00..25588.07 rows=504501 width=8) (actual time=0.273..0.273 rows=1 loops=1)
                       Index Cond: (id IS NOT NULL)
 Total runtime: 136.530 ms
(18 rows)

[Юрий]

Пересечений по условию у меня нет (проверял: один и тот же запрос на партицию и на мастер-таблицу отработал за одно и то же время). Кстати, руководствовался этим же примером :)

Ваш explain выдает «Index Scan», а мой «Seq Scan». Значит таблицу/индекс я создал все-таки как-то по другому. Спасибо, появилось, за что зацепиться — буду копать в этом направлении.

[galaxy]

Глядя вот на такие строчки:

-> Seq Scan on cdr_data_90mln cdr_data_master (cost=0.00..90934.00 rows=5000000 width=99) (actual time=10.520..6740.251 rows=5000000 loops=1)

я подумал, что может что-то не то с чеками, т.к. он зачем-то реально вытаскивает все данные из нескольких партиций.
Еще можно сделать принудительный ANALYZE всем дочерним таблицам, чтобы быть уверенным, что статистика актуальная.
Также посмотрите на параметры оптимизатора (всякие enable_xxxscan, enable_xxxjoin), не отличаются ли от дефолтных. Ну и числовые параметры (effective_cache_size, work_mem, shared_buffers etc) тоже на соответствие рекомендациям проверьте.

Answer 2

[Константин]

Я бы сказал, что там всётаки нету индексов, иначе бы небыло Seq Scan. Или индексы не включены.
«For each partition, create an index on the key column(s), as well as any other indexes you might want. (The key index is not strictly necessary, but in most scenarios it is helpful. If you intend the key values to be unique then you should always create a unique or primary-key constraint for each partition.)»
www.postgresql.org/docs/9.1/static/ddl-partitioning.html

Comments

[Юрий]

Либо лыжи не едут, либо я…

Вот скрин мастер-таблицы:



С потомка:

Answer 3

[Павел Назаров]

1. Проверьте следующий параметр:
SHOW constraint_exclusion ;
constraint_exclusion
----------------------
partition


2. Проверьте запрос с явным фильтром по партиционируемому полю (WHERE id > ...).

3. Если он ок, то скорее всего для приведенных вами запросов PostgreSQL будет пробегать все партиции, так как ему непонятно, к какой обращаться. Рекомендуют делать явные запросы к нужной партиции, либо фильтроваться по .

Всегда ваш :)

Comments

[Юрий]

1)
SHOW constraint_exclusion;
constraint_exclusion
----------------------
on

Это обязательно, т.к. на этом сервере у меня уже есть один хайлоад :)

2)
Страно, но на непартицированной таблице запрос отработал немного быстрее (38 сек против 50)

explain analyze (select * from cdr_data where id>20000000 and id<30000000);
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------
Bitmap Heap Scan on cdr_data (cost=3703.24..214997.03 rows=138384 width=418) (actual time=9416.847..31960.503 rows=8040678 loops=1)
Recheck Cond: ((id > 20000000) AND (id < 30000000))
-> Bitmap Index Scan on cdr_data_pkey (cost=0.00..3668.65 rows=138384 width=0) (actual time=9368.697..9368.697 rows=8040678 loops=1)
Index Cond: ((id > 20000000) AND (id < 30000000))
Total runtime: 38382.290 ms
(5 rows)

explain analyze (select * from cdr_data_master where id>60000000 and id<70000000);
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------------------
Result (cost=0.00..231735.26 rows=10000001 width=100) (actual time=0.014..43035.965 rows=9999999 loops=1)
-> Append (cost=0.00..231735.26 rows=10000001 width=100) (actual time=0.012..25708.944 rows=9999999 loops=1)
-> Index Scan using cdr_data_master_pkey on cdr_data_master (cost=0.00..4.26 rows=1 width=532) (actual time=0.005..0.005 rows=0 loops=1)
Index Cond: ((id > 60000000) AND (id < 70000000))
-> Seq Scan on cdr_data_65mln cdr_data_master (cost=0.00..115746.00 rows=5000000 width=100) (actual time=0.005..4875.700 rows=4999999 loops=1)
Filter: ((id > 60000000) AND (id < 70000000))
-> Seq Scan on cdr_data_70mln cdr_data_master (cost=0.00..115985.00 rows=5000000 width=100) (actual time=0.010..4975.571 rows=5000000 loops=1)
Filter: ((id > 60000000) AND (id < 70000000))
Total runtime: 50992.342 ms
(9 rows)

3) В том-то и дело, что должен пробегать не все партиции, а значит отрабатывать быстрее. На этом же сервере бегает база, где также реализовано партицирование, но только по колонке, в которой хранится время записи. И оно прекрасно работает (один и тот же запрос отрабатывает 3 сек на партицированной таблице, и более часа на непартицированной)! Поэтому я предполагаю, что я как-то индексы неправильно создал, но где ошибся, пока не найду.

[Павел Назаров]

Если вы еще не докопались, то есть пара вопросов.

1. Отдельный запрос по партиции с WHERE id >… нормально выполняется, с index scan?
2. Вы говорите, у вас есть другие таблицы с партициями — на них абсолютно аналогичные вопросы как выполняются?

Про статистику уже спросили :)
Да, +1 про апдейт до 9.1 — это вообще must-use совет (обновиться) — с каждой версией много плюшек вносят. В 9.2 вообще обещают выборку из покрывающего индекса сделать, это же киллер-фича, которая правда почти у всех есть ))

[Юрий]

1) Выполняется быстрее, но с Sec scan.
2) Не совсем аналогичные. Есть таблица с индексом на колонке с датой, там все работает как нужно (т.е. сканятся именно партиции), и скорость выполнения запроса на порядки быстрее на партицированной таблице по сравнению с непартицированной.

Обновление постараюсь накатить до конца рабочего дня.

Answer 4

[Павел Назаров]

Ааа, парсер.
>> фильтроваться по id

Answer 5

[galaxy]

Какая у Вас версия постгреса? archives.postgresql.org/pgsql-performance/2011-04/msg00385.php

Посмотрите еще, что будет c enable_seqscan=off. Может ему статистики не хватает на таблицах?

Comments

[Юрий]

> Посмотрите еще, что будет c enable_seqscan=off. Может ему статистики не хватает на таблицах?
Попробовал, не помогло.

> Какая у Вас версия постгреса? archives.postgresql.org/pgsql-performance/2011-04/msg00385.php
Вот это очень полезная информация! Версия у меня 9.0.4. Там очень похожая проблема: постгрес сканит sequence по всем партициям (судя по ауту explain analyze), но не сканит индекс. Пишут, что было пофиксено в 9.1. Попробую обновиться.
Спасибо!

Answer 6

[Константин]

Я всётаки не спец по таким вещам, но попробуйте проверить включены-ли индексы.
ALTER TABLE cdr_data_100mln ENABLE TRIGGER cdr_data_100mln_pkey;

ИМХО индексы я бы делал как hash. Потому, что B-TREE используются для поиска по словам/длинным значениям а HASH для точного поподания. CREATE INDEX cdr_data_100mln_hash_idx ON cdr_data_100mln USING hash;

Comments

[Юрий]

>Я всётаки не спец по таким вещам, но попробуйте проверить включены-ли индексы.
>ALTER TABLE cdr_data_100mln ENABLE TRIGGER cdr_data_100mln_pkey;

Прошу прощения, здесь какой триггер имеется ввиду? На insert у меня триггер есть. На select, если я правильно понимаю механизм партицирования, триггер не нужен, а нужно создать индекс по полю, по которому партицируем.

[Константин]

Индексы как такого в постгрес работают как триггеры.

Answer 7

[Юрий]

Приветствую, коллеги!
Обновился до 9.1.3. Работать стало побыстрее раза в два. Но все равно, не удовлетворительно.
Запрос по индексам из топика теперь выполняются 0.5 сек и 150 сек соответственно. Нужно ковыряться дальше. Но уже не знаю где :(

Comments

[galaxy]

а план не поменялся?
можете показать explain с enable_seqscan on и off?

[Константин]

Explain analyze В СТУДИЮ!

[Юрий]

Извиняюсь за долгий ответ — в праздники не было доступа к серверу.

1) непартицированная:
explain analyze (select * from cdr_data order by id desc limit 10);
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=0.00..0.46 rows=10 width=418) (actual time=61.820..96.951 rows=10 loops=1)
-> Index Scan Backward using cdr_data_pkey on cdr_data (cost=0.00..1268387.17 rows=27676900 width=418) (actual time=61.817..96.927 rows=10 loops=1)
Total runtime: 96.992 ms
(3 rows)


2) партицированная:
explain analyze (select * from cdr_data_master order by id desc limit 10);
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=1850530.19..1850530.21 rows=10 width=100) (actual time=278037.222..278037.245 rows=10 loops=1)
-> Sort (cost=1850530.19..1966777.30 rows=46498846 width=100) (actual time=278037.218..278037.227 rows=10 loops=1)
Sort Key: public.cdr_data_master.id
Sort Method: top-N heapsort Memory: 26kB
-> Result (cost=0.00..845706.84 rows=46498846 width=100) (actual time=14.359..213654.201 rows=46495464 loops=1)
-> Append (cost=0.00..845706.84 rows=46498846 width=100) (actual time=14.357..132664.369 rows=46495464 loops=1)
-> Seq Scan on cdr_data_master (cost=0.00..0.00 rows=1 width=532) (actual time=0.001..0.001 rows=0 loops=1)
-> Seq Scan on cdr_data_100mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
-> Seq Scan on cdr_data_105mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.000..0.000 rows=0 loops=1)
-> Seq Scan on cdr_data_10mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.000..0.000 rows=0 loops=1)
-> Seq Scan on cdr_data_110mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
-> Seq Scan on cdr_data_115mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.000..0.000 rows=0 loops=1)
-> Seq Scan on cdr_data_120mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
-> Seq Scan on cdr_data_125mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
-> Seq Scan on cdr_data_130mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
-> Seq Scan on cdr_data_135mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
-> Seq Scan on cdr_data_140mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
-> Seq Scan on cdr_data_145mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.000..0.000 rows=0 loops=1)
-> Seq Scan on cdr_data_150mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
-> Seq Scan on cdr_data_155mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
-> Seq Scan on cdr_data_15mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
-> Seq Scan on cdr_data_160mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
-> Seq Scan on cdr_data_165mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
-> Seq Scan on cdr_data_170mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
-> Seq Scan on cdr_data_175mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.000..0.000 rows=0 loops=1)
-> Seq Scan on cdr_data_180mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
-> Seq Scan on cdr_data_185mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.000..0.000 rows=0 loops=1)
-> Seq Scan on cdr_data_190mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
-> Seq Scan on cdr_data_195mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
-> Seq Scan on cdr_data_200mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.000..0.000 rows=0 loops=1)
-> Seq Scan on cdr_data_20mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
-> Seq Scan on cdr_data_25mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.000..0.000 rows=0 loops=1)
-> Seq Scan on cdr_data_30mln cdr_data_master (cost=0.00..35162.66 rows=1934658 width=100) (actual time=14.310..2524.045 rows=1934658 loops=1)
-> Seq Scan on cdr_data_35mln cdr_data_master (cost=0.00..4475.61 rows=247612 width=100) (actual time=16.907..320.907 rows=247612 loops=1)
-> Seq Scan on cdr_data_40mln cdr_data_master (cost=0.00..1949.81 rows=107813 width=100) (actual time=0.253..140.468 rows=107813 loops=1)
-> Seq Scan on cdr_data_45mln cdr_data_master (cost=0.00..2940.79 rows=162790 width=101) (actual time=0.233..201.041 rows=162790 loops=1)
-> Seq Scan on cdr_data_50mln cdr_data_master (cost=0.00..64148.52 rows=3532521 width=100) (actual time=0.260..4702.547 rows=3532521 loops=1)
-> Seq Scan on cdr_data_55mln cdr_data_master (cost=0.00..90983.00 rows=5000000 width=100) (actual time=12.778..6816.170 rows=5000000 loops=1)
-> Seq Scan on cdr_data_5mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
-> Seq Scan on cdr_data_60mln cdr_data_master (cost=0.00..90966.00 rows=5000000 width=100) (actual time=15.267..7191.117 rows=5000000 loops=1)
-> Seq Scan on cdr_data_65mln cdr_data_master (cost=0.00..90745.99 rows=4999985 width=100) (actual time=0.006..4416.925 rows=5000000 loops=1)
-> Seq Scan on cdr_data_70mln cdr_data_master (cost=0.00..90984.87 rows=4999873 width=100) (actual time=0.004..4479.866 rows=5000000 loops=1)
-> Seq Scan on cdr_data_75mln cdr_data_master (cost=0.00..90957.88 rows=4999883 width=100) (actual time=21.760..7057.975 rows=5000000 loops=1)
-> Seq Scan on cdr_data_80mln cdr_data_master (cost=0.00..90970.00 rows=5000000 width=99) (actual time=11.269..6761.104 rows=5000000 loops=1)
-> Seq Scan on cdr_data_85mln cdr_data_master (cost=0.00..90950.00 rows=5000000 width=99) (actual time=11.657..6516.789 rows=5000000 loops=1)
-> Seq Scan on cdr_data_90mln cdr_data_master (cost=0.00..90934.00 rows=5000000 width=99) (actual time=10.520..6740.251 rows=5000000 loops=1)
-> Seq Scan on cdr_data_95mln cdr_data_master (cost=0.00..9274.07 rows=510070 width=99) (actual time=9.752..695.643 rows=510070 loops=1)
Total runtime: 278037.660 ms
(48 rows)

Разницу только вижу в сортировке партиций :)