| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Cc: | Dilip Kumar <dilipbalaut(at)gmail(dot)com>, tender wang <tndrwang(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock |
| Date: | 2024-01-25 17:28:19 |
| Message-ID: | CA+TgmoZX_SLrbJ2+vM0p7z0P2Bj_S_Ne9QBZJR8kawJLbHc8UA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jan 25, 2024 at 11:22 AM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> Still with these auto-tuning GUCs, I noticed that the auto-tuning code
> would continue to grow the buffer sizes with shared_buffers to
> arbitrarily large values. I added an arbitrary maximum of 1024 (8 MB),
> which is much higher than the current value of 128; but if you have
> (say) 30 GB of shared_buffers (not uncommon these days), do you really
> need 30MB of pg_clog cache? It seems mostly unnecessary ... and you can
> still set it manually that way if you need it. So, largely I just
> rewrote those small functions completely.
Yeah, I think that if we're going to scale with shared_buffers, it
should be capped.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2024-01-25 17:30:55 | Re: [PATCH] Add native windows on arm64 support |
| Previous Message | Robert Haas | 2024-01-25 17:25:46 | Re: Emit fewer vacuum records by reaping removable tuples during pruning |