на графике чем больше шаред, тем меньше тпс

правая часть (75%) даёт больше TPS чем левая (25%)

хотя, когда вся в бд в шаред, то тпс больше вроде

См. личные сообщения

при маленьком шаред и большом файловом кеше тпс больше, чем при 25% шаред (как часто все рекомендуют) и 75 кэш

вот это интересно

на основании чего такой вывод? в правой части график практически горизонтальный

где больше тпс? при шаред 128 МБ (0%) или при 8 ГБ (25%)?

а… ну да. но следует учесть, что это синтетика — тут надо делать тесты под вашу нагрузку.
+ сам тест был на этой же машине, тоже могло повлиять

ессно, все параметры настраиваются индивидуально на каждом инстансе
просто обратил внимание, потому что везде в рекомендациях 25%

Часто ли используются PL/pgSQL блоки отдельно?

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

А Вы пробовали просто воспроизвести (кстати, зачем)?
Вообще, в документации пишут следующее:

Trying to update the same row twice in a single statement is not supported. Only one of the modifications takes place, but it is not easy (and sometimes not possible) to reliably predict which one. This also applies to deleting a row that was already updated in the same statement: only the update is performed. Therefore you should generally avoid trying to modify a single row twice in a single statement.

Попробовать и сравнить-то можно. Но для этого мониторинг должен быть, само собой.
И измениться всё может сильно, в принципе (т.е. оптимальная настройка может отличаться от default раза в три, например).

Benchmarking вообще штука сложная. Но откуда тут лишние человеко-часы?
На практике первичная вполне приемлемая настройка под "железо" / нагрузку занимает от силы час (и её можно выполнять как часть базовой настройки OS и PostgreSQL), нередко с существенным эффектом, так что обычно оно того стоит, нет?

Всем привет, нужен совет

оптимизирую запрос, в нем следующий отрывок:

Seq Scan on core_course  (cost=0.00..39.59 rows=70 width=908)
                          Filter: ((NOT is_removed) AND (published_at IS NOT NULL) AND (started_at >= '2021-01-21 19:44:02.212586'::timestamp without time zone))

Создаю индекс:
CREATE INDEX public_qs_index ON public.core_course USING btree (started_at, published_at, is_removed)

Но индекс не задействуется. Почему? Неправильно создал?

Seq Scan on core_course  (cost=0.00..39.59 rows=70 width=908)
                          Filter: ((NOT is_removed) AND (published_at IS NOT NULL) AND (started_at >= '2021-01-21 19:44:02.212586'::timestamp without time zone))

Потому что оно того не стоит, скорее всего, и PostgreSQL это правильно оценивает.
А вообще, лучше дать больше информации — в идеале всё то, что обычно требуется для того, чтобы подсказать по оптимизации запросов.

То, что вы описали — это называется «воображаемая оптимизация». Это примерно как компьютерные мастера, что смотрят на нас добрыми лицами с объявлений на дверях подъездов, своим клиентам диски дефрагментируют.

Seq Scan on core_course  (cost=0.00..39.59 rows=70 width=908)
                          Filter: ((NOT is_removed) AND (published_at IS NOT NULL) AND (started_at >= '2021-01-21 19:44:02.212586'::timestamp without time zone))

Строчек мало. Строчек в табличку добавьте.

А наблюдаемая разница в показателях средств мониторинга, отличия в результатах правильно проведённых benchmarks — тоже воображаемые? ;)
Т.е. аналогия тут некорректна.