Re: BitmapHeapScan streaming read user and prelim refactoring - Mailing list pgsql-hackers

From Melanie Plageman
Subject Re: BitmapHeapScan streaming read user and prelim refactoring
Date
Msg-id CAAKRu_Z5=0PnLHAJGVcHYWzOoP_6ebrgQ4pkMNGvQjewUNfFYw@mail.gmail.com
Whole thread Raw
In response to Re: BitmapHeapScan streaming read user and prelim refactoring  (Jakub Wartak <jakub.wartak@enterprisedb.com>)
Responses Re: BitmapHeapScan streaming read user and prelim refactoring
List pgsql-hackers
On Thu, Mar 13, 2025 at 5:46 AM Jakub Wartak
<jakub.wartak@enterprisedb.com> wrote:
>
> Cool, anything > 1 is just better. Just quick question, so now we have:
>
> #define DEFAULT_EFFECTIVE_IO_CONCURRENCY 16
> #define DEFAULT_MAINTENANCE_IO_CONCURRENCY 10
>
> Shouldn't maintenance be now also at the same value (16) instead of
> 10? Also, fc34b0d9de27 (5 years ago by Thomas) states about m_io_c:
> "Use the new setting in heapam.c instead of the hard-coded formula
> effective_io_concurrency + 10 introduced by commit 558a9165e08.", so
> there was always assumption that m_io_c > e_io_c (?) Now it's kind of
> inconsistent to see bitmap heap scans pushing more IOPs than
> recovery(!)/ANALYZE/VACUUM or am I missing something? No pressure to
> change, just asking what Your thoughts are.

Yea, I'm not really sure what if any relationship the two GUCs should
have to one another. As long as they are in the same ballpark, since
they are tuning for the same machine, I don't see any reason their
values need to be adjusted together. However, if it is confusing for
maintenance_io_concurrency default to be 10 while
effective_io_concurrency default is 16, I'm happy to change it. I just
don't quite know what I would write in the commit message. "it seemed
confusing that they weren't the same?"

- Melanie



pgsql-hackers by date:

Previous
From: Aleksander Alekseev
Date:
Subject: Proposal: manipulating pg_control file from Perl
Next
From: Tom Lane
Date:
Subject: Re: Proposal: manipulating pg_control file from Perl