On Saturday, November 26, 2011 09:52:17 PM Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > You could also try if it makes a difference reducing SnapshotData to one
> > instead of two cachelines. The data itself fits into one without
> > problems. Trivial patch attached.
> On what grounds do you argue that this patch gets SnapshotData into one
> cacheline today (and on what hardware), or that it will continue to do
> so in the future? If we're this close to the edge then any future
> addition to the struct will destroy the point. I'd just as soon keep
> the fields in a logical order.
To my knowledge there is no current and supported (i.e. I don't count Itanium)
hardware that doesn't have 64bit cachelines except in the embedded market.
I also don't see a movement towards 128bit cpus or anything else requiring
bigger pointers.
If platforms with 128bit cachelines or such would gain popularity - nothing
would be lost by that change.
Which change are you "afraid" of?
Now the holes I talked about obviously were on a 64bit machine. But there are
a few situations where improving layout so it fits with 8byte alignment for
pointers makes the situation worse for 32bit. Looking a bit careful at the
changes one does should catch those problems.
Also its not *that* close to overflowing again. It was 72 bytes before, now
its 56 on a 64bit x86 machine with linux abi.
I agree that logical order is important. I don't propose changing all structs
in pg mechanically.+
Its sad that there is no sensible method to let the compiler safely reorder
struct members accross compiler (-versions) and platforms...
Andres