Pushed a version (hopefully) fixing Tom's complaints.
On 2015-01-28 13:52:30 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2015-01-28 13:38:51 -0500, Tom Lane wrote:
#define BUFFERDESC_PADDED_SIZE (SIZEOF_VOID_P == 8 ? 64 : 32)
Hm, did you intentionally put a
On 2015-01-26 21:13:31 -0500, Robert Haas wrote:
On Mon, Jan 26, 2015 at 9:08 PM, Robert Haas robertmh...@gmail.com wrote:
Contrary opinions? Robert?
I'm totally OK with further aligning just that one allocation.
Of course, now that I think about it, aligning it probably works
mostly
On Wed, Jan 28, 2015 at 10:35 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2015-01-26 21:13:31 -0500, Robert Haas wrote:
So maybe we should also do something like what LWLocks do, and make a
union between the actual structure and an appropriate array
On 2015-01-28 10:35:28 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2015-01-26 21:13:31 -0500, Robert Haas wrote:
So maybe we should also do something like what LWLocks do, and make a
union between the actual structure and an appropriate array of padding
bytes -
Andres Freund and...@2ndquadrant.com writes:
On 2015-01-26 21:13:31 -0500, Robert Haas wrote:
So maybe we should also do something like what LWLocks do, and make a
union between the actual structure and an appropriate array of padding
bytes - say either 64 or 128 of them.
Hm. That's a bit
On 2015-01-28 13:38:51 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
I personally still think that a comment above sbufdesc's definition
would be sufficient for now. But whatever. I'll enforce 64byte padding
on 64bit platforms, and do nothing on 32bit platforms.
On 2015-01-28 17:08:46 +0100, Andres Freund wrote:
I just have no idea whether it'd be beneficial to use more space on
32bit to pad the individual entries. Since this mostly is beneficial on
multi-socket, highly concurrent workloads, I doubt it really matter.
I personally still think that a
Andres Freund and...@2ndquadrant.com writes:
I personally still think that a comment above sbufdesc's definition
would be sufficient for now. But whatever. I'll enforce 64byte padding
on 64bit platforms, and do nothing on 32bit platforms.
Patch doing that attached.
Surely the sizeof() in
Andres Freund and...@2ndquadrant.com writes:
On 2015-01-28 13:38:51 -0500, Tom Lane wrote:
#define BUFFERDESC_PADDED_SIZE (SIZEOF_VOID_P == 8 ? 64 : 32)
Hm, did you intentionally put a 32in there or was that just the logical
continuation of 64? Because there's no way it'll ever fit into
On Mon, Jan 26, 2015 at 8:04 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2015-01-26 19:58:25 -0500, Bruce Momjian wrote:
On Tue, Jan 27, 2015 at 01:43:41AM +0100, Andres Freund wrote:
master + 32align.patch:
-c max_connections=400
tps = 183791.872359 (high run vs. run variability)
On Mon, Jan 26, 2015 at 9:08 PM, Robert Haas robertmh...@gmail.com wrote:
Contrary opinions? Robert?
I'm totally OK with further aligning just that one allocation.
Of course, now that I think about it, aligning it probably works
mostly because the size is almost exactly one cache line. If it
On 2015-01-26 19:58:25 -0500, Bruce Momjian wrote:
On Tue, Jan 27, 2015 at 01:43:41AM +0100, Andres Freund wrote:
master + 32align.patch:
-c max_connections=400
tps = 183791.872359 (high run vs. run variability)
-c max_connections=401
tps = 185494.98244 (high run vs. run variability)
On 2015-01-05 21:43:04 -0500, Bruce Momjian wrote:
On Fri, Jan 2, 2015 at 06:25:52PM +0100, Andres Freund wrote:
I can't run tests right now...
What exactly do you want to see with these tests? that's essentially
what I've already benchmarked + some fprintfs?
I want to test two patches
On Tue, Jan 27, 2015 at 01:43:41AM +0100, Andres Freund wrote:
master + 32align.patch:
-c max_connections=400
tps = 183791.872359 (high run vs. run variability)
-c max_connections=401
tps = 185494.98244 (high run vs. run variability)
master + 64align.patch:
-c max_connections=400
tps =
On Thu, Jan 1, 2015 at 3:04 PM, Andres Freund and...@2ndquadrant.com wrote:
That's true, but if you don't align the beginnings of the allocations,
then it's a lot more complicated for the code to properly align stuff
within the allocation. It's got to insert a variable amount of
padding based on
On Fri, Jan 2, 2015 at 06:25:52PM +0100, Andres Freund wrote:
I can't run tests right now...
What exactly do you want to see with these tests? that's essentially
what I've already benchmarked + some fprintfs?
I want to test two patches that both allocate an extra 64 bytes but
shift the
On 2014-12-29 16:59:05 -0500, Bruce Momjian wrote:
diff --git a/src/backend/storage/buffer/buf_init.c
b/src/backend/storage/buffer/buf_init.c
new file mode 100644
index ff6c713..c4dce5b
*** a/src/backend/storage/buffer/buf_init.c
--- b/src/backend/storage/buffer/buf_init.c
***
On 2015-01-01 11:55:03 -0500, Robert Haas wrote:
On Mon, Dec 29, 2014 at 6:48 PM, Andres Freund and...@2ndquadrant.com wrote:
Andres reported the above 2x pgbench difference in February, but no
action was taken as everyone felt there needed to be more performance
testing, but it never
On Mon, Dec 29, 2014 at 6:48 PM, Andres Freund and...@2ndquadrant.com wrote:
Andres reported the above 2x pgbench difference in February, but no
action was taken as everyone felt there needed to be more performance
testing, but it never happened:
FWIW, I have no idea what exactly should be
On Thu, Jan 1, 2015 at 05:59:25PM +0100, Andres Freund wrote:
That seems like a strange approach. I think it's pretty sensible to
try to ensure that allocated blocks of shared memory have decent
alignment, and we don't have enough of them for aligning on 64-byte
boundaries (or even
On Thu, Jan 1, 2015 at 09:04:48PM +0100, Andres Freund wrote:
On January 1, 2015 8:49:06 PM CET, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jan 1, 2015 at 11:59 AM, Andres Freund and...@2ndquadrant.com
wrote:
The problem is that just aligning the main allocation to some
boundary
On January 1, 2015 8:49:06 PM CET, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jan 1, 2015 at 11:59 AM, Andres Freund and...@2ndquadrant.com
wrote:
The problem is that just aligning the main allocation to some
boundary
doesn't mean the hot part of the allocation is properly aligned.
shmem.c
On Thu, Jan 1, 2015 at 11:59 AM, Andres Freund and...@2ndquadrant.com wrote:
The problem is that just aligning the main allocation to some boundary
doesn't mean the hot part of the allocation is properly aligned. shmem.c
in fact can't really do much about that - so fully moving the
On Sat, Dec 27, 2014 at 08:05:42PM -0500, Robert Haas wrote:
On Wed, Dec 24, 2014 at 11:20 AM, Andres Freund and...@2ndquadrant.com
wrote:
I just verified that I can still reproduce the problem:
# aligned case (max_connections=401)
afreund@axle:~$ pgbench -P 1 -h /tmp/ -p5440 postgres
On 2014-12-29 16:59:05 -0500, Bruce Momjian wrote:
I am glad someone else considers this important.
I do consider it important. I just considered the lwlock scalability
more important...
Andres reported the above 2x pgbench difference in February, but no
action was taken as everyone felt
On Wed, Dec 24, 2014 at 11:20 AM, Andres Freund and...@2ndquadrant.com wrote:
I just verified that I can still reproduce the problem:
# aligned case (max_connections=401)
afreund@axle:~$ pgbench -P 1 -h /tmp/ -p5440 postgres -n -M prepared -c 96 -j
96 -T 100 -S
progress: 1.0 s, 405170.2
On Wed, Dec 24, 2014 at 10:30:19AM +0100, Andres Freund wrote:
On 2014-12-23 22:51:22 -0500, Bruce Momjian wrote:
Many of these are 64-byte aligned, including Buffer Descriptors.
In that case you need to change max_connections, some settings will lead
to unaligned BufferDescriptors.
Well,
On 2014-12-24 10:00:05 -0500, Bruce Momjian wrote:
On Wed, Dec 24, 2014 at 10:30:19AM +0100, Andres Freund wrote:
On 2014-12-23 22:51:22 -0500, Bruce Momjian wrote:
Many of these are 64-byte aligned, including Buffer Descriptors.
In that case you need to change max_connections, some
On Thu, Apr 17, 2014 at 11:23:24AM +0200, Andres Freund wrote:
On 2014-04-16 19:18:02 -0400, Bruce Momjian wrote:
On Thu, Feb 6, 2014 at 09:40:32AM +0100, Andres Freund wrote:
On 2014-02-05 12:36:42 -0500, Robert Haas wrote:
It may well be that your proposal is spot on. But I'd like
On Thu, Apr 17, 2014 at 11:23:24AM +0200, Andres Freund wrote:
On 2014-04-16 19:18:02 -0400, Bruce Momjian wrote:
On Thu, Feb 6, 2014 at 09:40:32AM +0100, Andres Freund wrote:
On 2014-02-05 12:36:42 -0500, Robert Haas wrote:
It may well be that your proposal is spot on. But I'd like
On 2014-04-16 19:18:02 -0400, Bruce Momjian wrote:
On Thu, Feb 6, 2014 at 09:40:32AM +0100, Andres Freund wrote:
On 2014-02-05 12:36:42 -0500, Robert Haas wrote:
It may well be that your proposal is spot on. But I'd like to see some
data-structure-by-data-structure measurements,
On Thu, Feb 6, 2014 at 09:40:32AM +0100, Andres Freund wrote:
On 2014-02-05 12:36:42 -0500, Robert Haas wrote:
It may well be that your proposal is spot on. But I'd like to see some
data-structure-by-data-structure measurements, rather than assuming that
alignment must be a good thing.
On 2014-02-05 12:36:42 -0500, Robert Haas wrote:
It may well be that your proposal is spot on. But I'd like to see some
data-structure-by-data-structure measurements, rather than assuming that
alignment must be a good thing.
I am fine with just aligning BufferDescriptors properly. That
Andres Freund and...@2ndquadrant.com writes:
And I think somebody already thought about it (c.f. ALIGNOF_BUFFER), it
just wasn't updated in the last 10 years.
No, ALIGNOF_BUFFER is there because we read something that said that I/O
transfers between userspace and kernel disk cache would be
On 2014-02-05 11:23:29 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
And I think somebody already thought about it (c.f. ALIGNOF_BUFFER), it
just wasn't updated in the last 10 years.
No, ALIGNOF_BUFFER is there because we read something that said that I/O
transfers
On Wed, Feb 5, 2014 at 11:37 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-02-05 11:23:29 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
And I think somebody already thought about it (c.f. ALIGNOF_BUFFER), it
just wasn't updated in the last 10 years.
No,
Hi,
In the nearby thread at
http://archives.postgresql.org/message-id/20140202140014.GM5930%40awork2.anarazel.de
Peter and I discovered that there is a large performance difference
between different max_connections on a larger machine (4x Opteron 6272,
64 cores together) in a readonly pgbench
37 matches
Mail list logo
