Три основных способа оптимизировать ваши запросы в PostgreSQL

[nuBacuk]

Одна и та же переменная и значения везде)

effective_cache_size = 24GB

[temadiary]

а ничо что индексы занимают место? и что бездумное использование их ни к чему хорошему не приводит?

про настройки это из копипаста многолетняя из вики постгреса и документации

[Akina]

Нет слов. чтобы выразиться...

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

[miruzzy]

Скорее это оптимизация работы кластера

Индексы - оптимизация чтения ( выполнения запросов)

А вот оптимизация запросов - это правильно писать сами запросы

[fedorro]

Это же OTUS - ведущие диванные эксперты ?

Хотя изредка у них встречаются и годные статьи.

[bigtrot]

Интересно, как сочетается pgbouncer и подготовленные запросы?

[rinace]

Важно корректировать значение shared_buffers в зависимости от нагрузки и профиля запросов. Это можно сделать с помощью pg_stat_activity

Или - "как собрать звездолет в гараже".

[EvgenyVilkov]

За любой материал и советы по индексированию в бд без упоминания понятия селективности и объяснения стоимости содержания индекса нужно отправлять прямиком в персональный ад где заставлять искать неиспользуемые и неэффективные индексы

[khgvghv]

Все-таки очень правильно Oracle, в свое время, четко делил оптимизацию на performance tuning и SQL tuning.

[Okunev_PY]

Такая прекрасная статья ни о чём, что даже комментировать не хочеться.

Накидали в кучу всего, ни слова как правильно писать запросы.

Какие конструкции в запросах к каким последствиям приводят, какие конструкции следует использовать и когда.

Короче сколько их статей не читал, вода водой.

[anokru]

Когда думаешь, что оптимизация твоего кривого запроса это индексирование... А ведь можно было раскрыть тему и устроить настоящий холивар в комментах, а не этот невзрачный пук.

[rinace]

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

Да хоть все таблицы в запросе индексами отложите .

"Ой у нас добавление и изменение данных стало тормозить "

Да, неужели . Вот, что бывает когда для разраба СУБД это просто ящик для хранения данных. Что там внутри они не знают , да и знать не хотят. У них фреймворки и ормы.

[VVitaly]

:-) Я бы добавил так... У них в голове "объекты"... Ну понятно что для объекта проще всего сделать GetObject(i) -> SetObjectProperties(j) -> WriteObject(i)....
А то что "за этим" стоит в БД им как бы "фиолетово"... И "получается" что вместо "update table set prop=x where id=i" в БД "получаем" select * from table where id=i (и это еще хорошо что в одной таблице, а могут выбирать все "свойства объекта" и из 10 по разным связкам + штук 5 "справочников") + зачастую могут выбирать и с блокировкой строк эксклюзивной и "подождать" реакции пользователя или удаленного сервиса с минуту + update (и хорошо если в одной таблице), а то могут обновить данные в нескольких связанных (ну вот такая у них "модель данных хранения")....
И все это у них называется "объектное программирование".... :-)

[rinace]

К сожалению это именно так :

У нас хороший код, мы уперлись в СУБД

выбирать и с блокировкой строк эксклюзивной и "подождать" реакции пользователя или удаленного сервиса с минуту

Они сами это открытым текстом признают и потом удивляются - почему на тестах все работало , в продуктивной нагрузке падает и тормозит.

Современный стиль разработки это - ....

[plumqqz]

Кто бы мог подумать.

"Общепринятое правило — устанавливать shared_buffers на уровне 25% от доступной оперативной памяти сервера. Например, для сервера с 32 ГБ RAM, значение будет таким:

effective_cache_size = 24GB