On Thu, Jun 05, 2025 at 12:47:52PM -0400, Tom Lane wrote:
> Andres Freund writes:
>> I think this is a big enough pitfall that it's, obviously assuming the patch
>> has a sensible complexity, worth fixing this in 18. RMT, anyone, what do you
>> think?
>
> Let's see the patch ... but yeah, I'd rat
Hi,
On 2025-06-05 12:47:52 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I think this is a big enough pitfall that it's, obviously assuming the patch
> > has a sensible complexity, worth fixing this in 18. RMT, anyone, what do you
> > think?
>
> Let's see the patch ... but yeah, I'd rather
Andres Freund writes:
> I think this is a big enough pitfall that it's, obviously assuming the patch
> has a sensible complexity, worth fixing this in 18. RMT, anyone, what do you
> think?
Let's see the patch ... but yeah, I'd rather not ship 18 like this.
regards, tom la
Hi,
On 2025-06-03 12:24:38 -0700, MARK CALLAGHAN wrote:
> When measuring the time to create a connection, it is ~2.3X longer with
> io_method=io_uring then with io_method=sync (6.9ms vs 3ms), and the
> postmaster process uses ~3.5X more CPU to create connections.
I can reproduce that - the reason
The new overhead for creating connections when io_method=io_uring is also a
function of max_connections. I have been using the default (=100). But when
I increase it to =1000 then the time to create a connection almost triples.
That isn't a big surprise given the usage of TotalProcs here:
https://g
