Hi,
On 2025-09-06 09:12:19 -0400, Robert Treat wrote:
> On Tue, Aug 26, 2025 at 9:32 AM Jakub Wartak
> wrote:
> > On Tue, Jul 8, 2025 at 5:22 AM Andres Freund wrote:
> > > On 2025-06-30 12:27:10 -0400, Andres Freund wrote:
> > > After addressing most of Greg's and Jim's feedback, I pushed this.
Hi Andres / Robert,
On Mon, Sep 8, 2025 at 5:55 PM Andres Freund wrote:
>
> Hi,
>
> On 2025-09-06 09:12:19 -0400, Robert Treat wrote:
[..]
> > > [..], but 6.1 is the LTS kernel, so plenty of people
> > > are going to hit those regressions with io_uring io_method, won't
> > > they?
>
> I doubt it,
On Tue, Aug 26, 2025 at 9:32 AM Jakub Wartak
wrote:
> On Tue, Jul 8, 2025 at 5:22 AM Andres Freund wrote:
> >
> > 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:
> > > > >
On Tue, Jul 8, 2025 at 5:22 AM Andres Freund wrote:
>
> 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 pitfal
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
15 matches
Mail list logo
