Cache hit rate super important to pay attention to in Postgres. What’s yours? SELECT sum(heap_blks_read) as heap_read, sum(heap_blks_hit) as heap_hit, (sum(heap_blks_hit) - sum(heap_blks_read)) / sum(heap_blks_hit) as ratio FROM pg_statio_user_tables;
-
-
-
Replying to @pg_xocolatl @craigkerstiens
My wild guess would be because when using a Cloud instance or VM you can easily upgrade to more RAM if you see you need more than anticipated...
1 reply 0 retweets 0 likes -
Replying to @tapoueh @craigkerstiens
The query provided shows you no such thing.
1 reply 0 retweets 0 likes -
Replying to @pg_xocolatl @craigkerstiens
My current reading of it is that it shows if you’re hitting the file system cache rather than the disks (hit/miss). The cache size depends on the RAM available. Is that reading all wrong?
1 reply 0 retweets 0 likes -
Replying to @tapoueh @craigkerstiens
Yes, your reading is wrong. It is only showing you what is happening with shared_buffers. You have no idea if you’re hitting the disks or not.
2 replies 0 retweets 2 likes -
Replying to @pg_xocolatl @craigkerstiens
Long time I have not had to inquire about such things now. I seem to remember there was a way to have the information I imagined was retrieved, is that the case? Would you be so helpful as to say how to get at it?
1 reply 0 retweets 1 like
The only thing that gets OS-level block I/O stats, AFAIK, is the log_*_stats settings (log_statement_stats / log_executor_stats) which don't know about parallelism and only report the change in getrusage of the current backend.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.