On Saturday, November 26, 2011 09:52:17 PM Tom Lane wrote: > Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
