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
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 |