Бенчмарк запросов postgres

Понятно, что это кеш, но может можно его отключить?

Вам надо чтоб запросы дольше выполнялись или что?

Смотрите планы ваших запросов (explain), думайте что и где подкрутить чтоб получить лучшую производительность. Но если нет хороших знаний в этой области можете еще и хуже сделать если начнете вносить правки.

Короче говоря, какая цель всего этого мероприятия?

Это секта. Они истязают себя посредством отключения кешей. Иногда даже во время тестов напрягают сервер другими приложениями. Активно вовлекают малолетних. Во избежание проблем с полицией, от них надо держаться подальше.

Цель сравнить по производительности 2 запроса, который делают одно и тоже. Например в первом запросе будет join, а во втором запросе основной запрос вынесен в cte, а join уже делать к cte. Но как их по производительности сравнить, если все время показывают разное время выполнения? То один быстрее, то другой.

https://stackoverflow.com/questions/1216660/see-and-clear-postgres-caches-buf...

Так анализируйте планы.

Я так понимаю вы выбираете какой вариант стоит использовать в «реальных» условиях. Но идея в том что в реальных условиях у вас как раз таки кэш будет, плюс кэш на дисках, плюс куча другой сопутствующей нагрузки. Так что если вам нужно какой-то близкий к реальности тест - устраивайте нагрузочное тестирование с реальным профилем нагрузки на данных, аналогичных реальным. Если вас интересуют цифры в вакууме - смотрите планы запросов.

Попробуй в where прописывать ничего не значащее условие но каждый раз разное, типа 1 == 1, ну или id != -101 где число меняется каждый запрос. Конечно если оптимизатор очень умный то может не сработать, просто скорее всего матчится запрос на выборку, запрос поменяется выборка заново построится.

Например простой запрос: select count(id) from table колеблется сейчас от 1.320ms до 1.560ms

Когда-то наблюдал разбросы в микробенчмарках из-за «cool and quite» в процессоре, когда проц сбрасывал частоту а шедулер кидал активный процесс по разным ядрам.

Цель сравнить по производительности 2 запроса

сравнивай планы, ибо время от лукавого. сейчас время одно, завтра привалят данные и время станет совсем другим. поэтому только вся мощЪ интелекта при рассматривании планов запроса.

Разное время при разных user_id может быть по 100500 причин, начиная от отсутствия препаре (соответственно оптимизатор многое знает про кол-во в результате и т.п.) до дефрагментарованных таблиц.

Как проводить сравнение запросов по производительности? Допустим есть запрос select, у которого в условиях указываешь user_id. Так вот он выполняется он около 8 секудн, после второго вызова уже выполняется около 100-300 милисекунд...

Естественно, вы должны анализировать время выполнения запроса СУБД-шкой, а не время извлечения данных из кэша )

И сравнивать надо не какие-то совершенно разные запросы - в таком сравнении просто нет никакого практического смысла (естественно, время их выполнения может быть абсолютно разным). Надо смотреть время выполнения конкретных запросов на данных разного объема, при наличии или отсутствии каких-то индексов и пр. Ну или сравнивать время выполнения запросов, сформулированных разными способами, но выдающих одни и те же данные. Ваша же цель - ускорить работу приложения, а не сравнить «ежа с ужом» :)