Друзья, подскажите плз. Есть таблица очень маленькая, записей в 20-30. Но по

ней происходит очень-очень много чтений.
И explain показывает, что происходит seq scan.
Можно ли закэшировать эту таблицу, чтобы данные в большинстве случаев брались из кэша?

Она и так закэшырована. Ну, скорее всего. Данные из кэша (shared_buffers) вымываются по LRU -- если с прошлого чтения все shared_buffers не повыкидывались -- то останутся там.

если там записей 20-30, чего там кешировать то ? вот и постгрес видимо так же думает, что ему сканить все быстрее, чем читать индекс)

И да, "почему происходит seq scan" -- это другой вопрос (в данном случае -- вполне очевидный).

Так вот, seq scan -- потому, что b-tree index lookup это относительно сложная процэдура. Во много раз более сложная, чем тупо взять tuple из странички. Потому 30 туплов быстрее просто взять, чем пытаться их как-то искать по индэксу (там, кстати, тожэ одна страничка будет, из которой, скорее всего, придётся этих туплов вытащить штук 5 чтобы найти нужный).

Да, похоже на то. Но меня смущает то, что иногда, когда очень много запросов, то происходит торможение. При чем время запроса может увеличиваться до 400 мс. А на графике я вижу "свечу". При чем, в статистике локов нет.... Я подумал, вдруг можно как-то в оперативку / shared ...что-то там положить

Насколько я помню, seq scan не через shared buffers проходит или не всегда через него. Для этого ограниченный ring buffer используется.

Это и так очевидно. Я говорю, что мне нужно еще быстрее!

Вообще не помню никакого ring buffer в postgres. А seq scan происходит всегда через shared buffers, разумеется -- никаких других методов поднять страницу, лежащую на диске у postgres просто нет.

Уж не в моменты checkpoint ли?

может нужно кешировать результат на стороне приложения ? чтобы не дергать то что особо не изменяется , а если и дергать то реже ?

Мне нравиться идея, тоже думал об этом...

Но вообще да, с предсказуемостью скорости и realtime у постгреса не очень всё хорошо.

Кстати, в этом направлении я не смотрел...

Вы не помните, а он есть) но используется для больших таблиц, что не случай автора.

А как проверить, что это checkpoint?

А на хосте, где PG стоит ничего другого не запущено?

Да, запущено. Параллельно несколько баз) Я тоже предположил, что они афектят. Но я не админ и не дба. Вот гадаю

Ну это плохо, конечно. PG использует страничный кэш операционной системы. Поэтому несколько баз могут афектить друг друга. Одна бд может загрязнять страничный кэш своими данными и вытеснять страницы другой бд, что приведет в дальнейшем к чтению с диска, а не из страничного кэша

А общих страниц у двух кластеров априори не должно быть

Есть параметр log_checkpoints.

Но на маленьку таблицу можно поставить грелочку, чтобы из shared_buffers её никогда не выкидывало!

> Но по ней происходит очень-очень много чтений. А откуда Вы получили вот эту информацию, конкретно?

Благодарствую!

тут уж зависит от многих факторов и "никогда" врядли можно гарантировать

К сожалению да. Надо, надо брать себя за шкирку и писать расшырение, которое memloчит указанные страницы!

Точнее, прибивает их в shared buffers в первую очередь. Мемлочить -- во вторую, там несложно ужэ.