| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Hugh Ranalli <hugh(at)whtc(dot)ca>, pgsql-performance(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Perplexing, regular decline in performance |
| Date: | 2019-07-17 18:52:54 |
| Message-ID: | 20190717185254.3ckjpiujkctm4b4i@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Hi
On 2019-07-17 13:55:51 -0400, Alvaro Herrera wrote:
> Be careful with pg_buffercache though, as it can cause a hiccup in
> operation.
I think that's been fixed a few years back:
commit 6e654546fb61f62cc982d0c8f62241b3b30e7ef8
Author: Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi>
Date: 2016-09-29 13:16:30 +0300
Don't bother to lock bufmgr partitions in pg_buffercache.
That makes the view a lot less disruptive to use on a production system.
Without the locks, you don't get a consistent snapshot across all buffers,
but that's OK. It wasn't a very useful guarantee in practice.
Ivan Kartyshov, reviewed by Tomas Vondra and Robert Haas.
Discusssion: <f9d6cab2-73a7-7a84-55a8-07dcb8516ae5(at)postgrespro(dot)ru>
so everything from 10 onwards ought to be fine.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gavin Flower | 2019-07-17 22:54:44 | Re: Searching in varchar column having 100M records |
| Previous Message | Alvaro Herrera | 2019-07-17 17:55:51 | Re: Perplexing, regular decline in performance |