Re: Fastest memmove in C

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: "FarjadFarid(ChkNet)" <farjad(dot)farid(at)checknetworks(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Fastest memmove in C
Date: 2016-07-07 16:33:51
Message-ID: 20160707163351.GY21416@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

* Merlin Moncure (mmoncure(at)gmail(dot)com) wrote:
> Well, testing is the key here. Microbechmarks demonstrating the value
> are not enough; proven statistically relevant benchmarks generated
> from postgres are the data points needed to make an assessment. My
> recommendation would be to dynamically link in these routines to
> postgres and start running a battery of memory heavy tests (start with
> pgbench -S on a small database). Ideally you could tease out some
> measurable benefit; license discussions and formal integration
> strategies are secondary to that IMO.

While I agree with this, I'm trying to figure out why this isn't being
incorporated into glibc instead..? Perhaps I missed it, but I didn't
see a discussion of that in the article. I'd certainly rather rely on
glibc if we can, though I know that we've ended up implementing our own
routines at times too. On the other hand, if there's a reason the glibc
folks don't want this, we should consider that..

Thanks!

Stephen

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2016-07-07 17:01:35 Re: Fastest memmove in C
Previous Message Merlin Moncure 2016-07-07 16:23:27 Re: Fastest memmove in C