From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Manfred Spraul <manfred(at)colorfullife(dot)com> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: Align large shared memory allocations |
Date: | 2003-09-20 21:55:26 |
Message-ID: | 29494.1064094926@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Manfred Spraul <manfred(at)colorfullife(dot)com> writes:
> Attached is a patch that aligns large shared memory allocations beyond
> MAXIMUM_ALIGNOF. The reason for this is that Intel's cpus have a fast
> path for bulk memory copies that only works with aligned addresses.
This patch is missing a demonstration that it's actually worth anything.
What kind of performance gain do you get?
> One problem is the "32" - it's arbitrary, it probably belongs into an
> arch dependant header file. But where?
We don't really have arch-dependent header files. What I'd be inclined
to do is "#define ALIGNOF_BUFFER 32" in pg_config_manual.h, then
#define BUFFERALIGN(LEN) to parallel the other TYPEALIGN macros in c.h,
and finally use that in the ShmemAlloc code.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-09-20 22:06:20 | Re: pgsql-server/src/backend catalog/index.c comma ... |
Previous Message | Tom Lane | 2003-09-20 21:48:47 | Re: PostgreSQL not ACID compliant? |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-09-20 22:06:20 | Re: pgsql-server/src/backend catalog/index.c comma ... |
Previous Message | Marc G. Fournier | 2003-09-20 21:45:24 | Re: pgsql-server/src/backend catalog/index.c comma ... |