> On 26 Sep 2023, at 10:36, Adrien Nayrat wrote:
> Should Postgres support alternative SSL libraries has HAProxy?
PostgreSQL can be built with LibreSSL instead of OpenSSL, which may or may not
be a better option performance wise for a particular application. Benchmarking
your workload is key to
Hello,
I read this article from Haproxy, they noticed OpenSSL v3 has huge
performance regressions :
https://github.com/haproxy/wiki/wiki/SSL-Libraries-Support-Status#openssl
This is a known issue :
https://github.com/openssl/openssl/issues/17627#issuecomment-1060123659
Unfortunately, v3
On 11/9/20 9:29 AM, Vik Fearing wrote:
> Hello,
>
> I've been doing some benchmarking on recent version of PostgreSQL and
> I'm seeing some regressions. The benchmark setup is as described in [1]
> except it looks like I got lucky in the runs used for that article.
>
> After many more runs, I ge
Hello,
I've been doing some benchmarking on recent version of PostgreSQL and
I'm seeing some regressions. The benchmark setup is as described in [1]
except it looks like I got lucky in the runs used for that article.
After many more runs, I get these NOPM averages (hopefully formatting
will surv
On 2018-01-08 14:38:20 +1300, Thomas Munro wrote:
> Just an idea, not sure if it's worth looking into; maybe we already
> spend enough time filling those buffers that a 50% syscall markup
> won't hurt.
Yea, I suspect that won't make a huge difference - copying an 8kb buffer
is typically a lot more
On Mon, Jan 8, 2018 at 1:32 PM, Thomas Munro
wrote:
> Also pgarch.c, syncrep.c, walsender.c and walreceiver.c use
> PostmasterIsAlive() every time through their loops[1] generating extra
> syscalls, one instance of which has caused complaints before[1] on a
> system where the syscall was expensive
On Mon, Jan 8, 2018 at 2:38 PM, Thomas Munro
wrote:
> On Fri, Jan 5, 2018 at 6:28 AM, Robert Haas wrote:
>> On Tue, Jan 2, 2018 at 5:23 PM, Andres Freund wrote:
>>> Note that real-world scenarios probably will see somewhat smaller
>>> impact, as this was measured over a loopback unix sockets whi
On Fri, Jan 5, 2018 at 6:28 AM, Robert Haas wrote:
> On Tue, Jan 2, 2018 at 5:23 PM, Andres Freund wrote:
>> Note that real-world scenarios probably will see somewhat smaller
>> impact, as this was measured over a loopback unix sockets which'll have
>> smaller overhead itself than proper TCP sock
On Tue, Jan 2, 2018 at 5:23 PM, Andres Freund wrote:
> To get closer to the worst case, I've also measured:
>
> pgbench SELECT 1, 16 clients, i7-6820HQ CPU (skylake):
>
> pti=off:
> tps = 420490.162391
>
> pti=on:
> tps = 350746.065039 (~0.83x)
>
> pti=on, nopcid:
> tps = 324269.903152 (~0.77x)
>
Don't want to go into that here.
The fix will unfortunately cause performance regressions. Depending on
the hardware version and kernel version (will not be backported for
every version) hardware features (PCID / ASID) will be used to reduce
the impact.
pti is the workaroud, page table isolat
10 matches
Mail list logo
