Re: Streaming I/O, vectored I/O (WIP)

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Melanie Plageman <melanieplageman(at)gmail(dot)com>
Subject: Re: Streaming I/O, vectored I/O (WIP)
Date: 2024-03-29 07:01:25
Message-ID: CA+hUKGLncY4sqa1RwoRwY_qq+2Fd-_0X3mDKk_p15sipmXZOng@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 29, 2024 at 9:45 AM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> master (213c959a29): 8.0 s
> streaming-api v13: 9.5 s

Hmm, that's not great, and I think I know one factor that has
confounded my investigation and the conflicting reports I have
received from a couple of people: some are using meson, which is
defaulting to -O3 by default, and others are using make which gives
you -O2 by default, but at -O2, GCC doesn't inline that
StartReadBuffer specialisation that is used in the "fast path", and
possibly more. Some of that gap is closed by using
pg_attribute_inline_always. Clang fails to inline at any level. So I
should probably use the "always" macro there because that is the
intention. Still processing the rest of your email...

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Guo 2024-03-29 07:06:07 Re: To what extent should tests rely on VACUUM ANALYZE?
Previous Message jian he 2024-03-29 06:56:47 Re: Can't find not null constraint, but \d+ shows that