Re: BitmapHeapScan streaming read user and prelim refactoring

On Mon, Mar 17, 2025 at 10:46 PM Melanie Plageman
<melanieplageman(at)gmail(dot)com> wrote:
>
> On Mon, Mar 17, 2025 at 2:55 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> >
> > On 2025-03-17 14:52:02 -0400, Melanie Plageman wrote:
> > > I don't feel strongly that we need to be as rigorous for
> > > maintenance_io_concurrency, but I'm also not sure 160 seems reasonable
> > > (which would be the same ratio as before).
> >
> > I'd lean towards just setting them to the same value for now.
>
> Cool, here's the patch I intend to commit. I had a bit of trouble
> clearly explaining the situation in the commit message which is why I
> didn't directly commit it. If no one has ideas on how to clarify it
> by tomorrow, I'll just push it.

Hi Melanie, same (160 is probably way too high for default m_io_c on
default/small systems with s_b=128MB, but the same value is probably
fine), so +1.

One may say that higher m_io_c may hurt , but at least for
startup/recovery performance see image [1] (from thread [2]) - it
shows running it on NVMe with m_io_c=128 and being faster than
default =10 and later Tomas V. pushed it even into value of "500" [3].
Hope that helps.

-J.

[1] https://www.postgresql.org/message-id/attachment/116928/trandomuuids-without-FPW-1.5kTPS_lagOverSize.csv-comments.png
[2] https://www.postgresql.org/message-id/VI1PR0701MB69608CBCE44D80857E59572EF6CA0%40VI1PR0701MB6960.eurprd07.prod.outlook.com
[3] https://www.postgresql.org/message-id/c5d52837-6256-0556-ac8c-d6d3d558820a%40enterprisedb.com