Hi,
On 2025-06-30 12:27:10 -0400, Andres Freund wrote:
> On 2025-06-05 14:32:10 -0400, Andres Freund wrote:
> > 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 sen
Hi,
On 2025-06-30 13:57:28 -0500, Jim Nasby wrote:
> +#if defined(HAVE_LIBURING_QUEUE_INIT_MEM) && defined(IORING_SETUP_NO_MMAP)
> && 1
>
> Is that && 1 intentional?
It was for testing both branches...
> Nit:
> + "mmap(%zu) to determine io_uring_queue_init_mem() support has failed: %m",
> IMHO
Hi,
On 2025-06-30 15:31:14 -0400, Burd, Greg wrote:
> > On Jun 30, 2025, at 12:27 PM, Andres Freund wrote:
> > On 2025-06-05 14:32:10 -0400, Andres Freund wrote:
> >> 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,
> On Jun 30, 2025, at 12:27 PM, Andres Freund wrote:
>
> Hi,
>
> On 2025-06-05 14:32:10 -0400, Andres Freund wrote:
>> 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 se
+#if defined(HAVE_LIBURING_QUEUE_INIT_MEM) && defined(IORING_SETUP_NO_MMAP)
&& 1
Is that && 1 intentional?
Nit:
+ "mmap(%zu) to determine io_uring_queue_init_mem() support has failed: %m",
IMHO that would read better without "has".
+ /* FIXME: This should probably not stay at DEBUG1? */
+ elog(D
Hi,
On 2025-06-05 14:32:10 -0400, Andres Freund wrote:
> 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
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
11 matches
Mail list logo
