"How do we size shared_buffers? A common starting rule of thumb is:"
I have an improved rule of thumb:
Give a lot of RAM. Give it all the RAM you can. And then buy some more and also give it to shared_buffers. Buffering data in RAM/CPU cache is crucial for performance.
Does not instill confidence when the queries they provide don't work.
For anyone curious, the corrected query:
SELECT sum(blks_hit)::numeric / nullif(sum(blks_hit + blks_read), 0) AS cache_hit_ratio FROM pg_stat_database;
I just ran their query, and it works
It does not in PG17.
Works on this Postgres 17.7:
postgres=# show server_version; server_version ------------------------------- 17.7 (Debian 17.7-3.pgdg13+1) (1 row)
postgres=# SELECT sum(blks_hit)/nullif(sum(blks_hit+blks_read),0) AS cache_hit_ratio FROM Pg_stat_database; cache_hit_ratio ------------------------ 0.99448341937558994728 (1 row)
I generally use this: https://pgtune.leopard.in.ua/
Yup, I was expecting pgtune being mentioned in the article.
And maybe something like HammerDB to check performances.
Nice tool. Do you know maybe similar tool for MySQL ?
[flagged]
"How do we size shared_buffers? A common starting rule of thumb is:"
I have an improved rule of thumb:
Give a lot of RAM. Give it all the RAM you can. And then buy some more and also give it to shared_buffers. Buffering data in RAM/CPU cache is crucial for performance.