From: | Peter Geoghegan <peter(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: additional error fields |
Date: | 2012-05-01 17:56:13 |
Message-ID: | CAEYLb_U2hRk2g9-Nshoo7kmJeUU0vLm31jxxJtkOyVva-+N+Pg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 1 May 2012 17:22, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Yeah. I also noticed in my benchmarking that sprintf() seemed to be
> very slow, to the point where I wondered whether we ought to have our
> own minimal version of sprintf() just for error strings.
Which sprintf()? You're probably aware that we already have a memset
replacement, MemSet, and indeed we even have a pg_sprintf(). Without
saying that we shouldn't do that, I'd caution against it. I use glibc
2.14.90, and for example my system's memcpy is implemented with
various optimisation that are only applicable to the architecture of
my system - SSE3 optimisations. A quick google throws up
http://sources.redhat.com/ml/libc-alpha/2010-01/msg00016.html .
Ditto every other architecture (most of these are from a recent
revision of glibc from SCM):
[peter(at)peterlaptop ~]$ locate memcpy.S
/home/peter/glibc/sysdeps/i386/i586/memcpy.S
/home/peter/glibc/sysdeps/i386/i686/memcpy.S
/home/peter/glibc/sysdeps/i386/i686/multiarch/memcpy.S
/home/peter/glibc/sysdeps/ia64/memcpy.S
/home/peter/glibc/sysdeps/powerpc/powerpc32/a2/memcpy.S
/home/peter/glibc/sysdeps/powerpc/powerpc32/cell/memcpy.S
/home/peter/glibc/sysdeps/powerpc/powerpc32/power4/memcpy.S
/home/peter/glibc/sysdeps/powerpc/powerpc32/power6/memcpy.S
/home/peter/glibc/sysdeps/powerpc/powerpc32/power7/memcpy.S
/home/peter/glibc/sysdeps/powerpc/powerpc64/memcpy.S
/home/peter/glibc/sysdeps/powerpc/powerpc64/a2/memcpy.S
/home/peter/glibc/sysdeps/powerpc/powerpc64/cell/memcpy.S
/home/peter/glibc/sysdeps/powerpc/powerpc64/power4/memcpy.S
/home/peter/glibc/sysdeps/powerpc/powerpc64/power6/memcpy.S
/home/peter/glibc/sysdeps/powerpc/powerpc64/power7/memcpy.S
/home/peter/glibc/sysdeps/s390/s390-32/memcpy.S
/home/peter/glibc/sysdeps/s390/s390-64/memcpy.S
/home/peter/glibc/sysdeps/sh/memcpy.S
/home/peter/glibc/sysdeps/sparc/sparc32/memcpy.S
/home/peter/glibc/sysdeps/sparc/sparc32/sparcv9/memcpy.S
/home/peter/glibc/sysdeps/sparc/sparc32/sparcv9/multiarch/memcpy.S
/home/peter/glibc/sysdeps/sparc/sparc64/memcpy.S
/home/peter/glibc/sysdeps/sparc/sparc64/multiarch/memcpy.S
/home/peter/glibc/sysdeps/x86_64/memcpy.S
/home/peter/glibc/sysdeps/x86_64/multiarch/memcpy.S
/home/peter/llvm/projects/compiler-rt/lib/arm/aeabi_memcpy.S
/usr/src/debug/glibc-2.14-394-g8f3b1ff/sysdeps/x86_64/memcpy.S
/usr/src/debug/glibc-2.14-394-g8f3b1ff/sysdeps/x86_64/multiarch/memcpy.S
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
From | Date | Subject | |
---|---|---|---|
Next Message | Brian Weaver | 2012-05-01 18:09:37 | Re: Problem with multi-job pg_restore |
Previous Message | Tom Lane | 2012-05-01 17:44:06 | Re: Problem with multi-job pg_restore |