Как да подобря производителността на базирани на дата заявки за голяма таблица?

материализиран изглед е пътят за това, което очертахте. Запитването на данни само за четене от последните месеци работи без да ги опреснявате. Може да искате да поставите в специален случай текущия месец, ако трябва да покриете и това.

Базовата заявка все още може да се възползва от индекс и има две посоки, които можете да предприемете:

Първо, частични индекси като сега няма да купи много в твоя сценарий, не си струва. Ако събирате още много месеци данни и най-вече правите заявки по месеци (и добавяте/пускате редове по месеци) разделяне на таблица може да е идея, тогава вашите индекси също са разделени автоматично. Все пак бих обмислил Postgres 11 или дори предстоящия Postgres 12 за това.)

Ако вашите редове са широки , създайте индекс, който позволява сканиране само за индекс . Като:

CREATE INDEX reportimpression_covering_idx ON reportimpression(datelocal, views, gender);

Свързани:

Как PostgreSQL изпълнява ORDER BY, ако в това поле е изграден индекс на b-дърво?

Или INCLUDE допълнителни колони в Postgres 11 или по-нова версия:

CREATE INDEX reportimpression_covering_idx ON reportimpression(datelocal) INCLUDE (views, gender);

Друго , ако вашите редове са физически сортирани по datelocal , помислете за BRIN индекс . Той е изключително малък и вероятно толкова бърз, колкото индекс на B-дърво за вашия случай. (Но тъй като е толкова малък, ще остане в кеша много по-лесно и няма да изтласква толкова много други данни.)

CREATE INDEX reportimpression_brin_idx ON reportimpression USING BRIN (datelocal);

Може да се интересувате от CLUSTER или pg_repack за физическо сортиране на редовете на таблицата. pg_repack може да го направи без изключителни заключвания на таблицата и дори без btree индекс (изисква се от CLUSTER ). Но това е допълнителен модул, който не се доставя със стандартната дистрибуция на Postgres.

Свързани: