Оптимизировать таблицу PostgreSQL для последовательного сканирования

Допустим, в базе данных PostgreSQL есть таблица:

\d+ game_user

                           Table "public.game_user"
  Column  |      Type      |                       Modifiers                 | Storage 
----------+----------------+-------------------------------------------------+---------
 id       | bigint         | not null default nextval('gu_id_seq'::regclass) | plain
 created  | timestamptimez | not null default now()                          | plain
 modified | timestamptz    | not null default now()                          | plain
 status   | smallint       | not null default 1                              | plain
 user_id  | bigint         | not null                                        | plain
 game_id  | bigint         | not null                                        | plain
 referrer | varchar(128)   | default NULL::character varying                 | extended
 extra    | json           | default '{}'::json                              | extended
 nickname | varchar(32)    | default NULL::character varying                 | extended

Интересно здесь выглядит Storage столбец. Можно ли как-то оптимизировать хранение таблицы на диске? Например, если у меня много seq scans над такой таблицей, кажется разумным иметь как можно более локализованный макет таблицы. Кроме того, меньший размер таблицы может позволить эффективно использовать кеш страницы ОС, и все чтения таблиц могут происходить из памяти. Как различные типы хранилищ (plain, main, extended и т. Д.) Влияют на такие вещи и как я могу настроить свою таблицу для ее оптимизации?


person Ivan Velichko    schedule 22.06.2016    source источник
comment
Прочтите это: https://www.postgresql.org/docs/current/static/storage-toast.html   -  person Nick Barnes    schedule 22.06.2016


Ответы (1)


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

Тем не менее, и поскольку вы спрашиваете о TOAST, единственный столбец, который может храниться вне очереди, - это extra, потому что это единственный столбец, который может вырасти до достаточно большого размера.
TOAST действительно может ускорить последовательное сканирование до тех пор, пока вы не выбираете столбец TOASTed, потому что в этом случае значение даже не будет считано с диска.
Это не поможет вам с SELECT * FROM game_user.

person Laurenz Albe    schedule 22.06.2016