AW: BUG #15923: Prepared statements take way too much memory.

Thanks for the insightful and interesting comments. 

-----Ursprüngliche Nachricht-----
Von: Thomas Munro <thomas.munro@gmail.com> 
Gesendet: Montag, 29. Juli 2019 08:11
An: Daniel Migowski <dmigowski@ikoffice.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>; Andres Freund <andres@anarazel.de>; pgsql-bugs@lists.postgresql.org
Betreff: Re: BUG #15923: Prepared statements take way too much memory.

On Sun, Jul 28, 2019 at 11:14 PM Daniel Migowski <dmigowski@ikoffice.de> wrote:
> * Why are MemoryContextAllocZeroAligned and MemoryContextAllocZero the same function?

It's not really relevant to the discussion about memory usage, but since you asked about
MemoryContextAllocZeroAligned:

I noticed that stuff a while back when another project I follow was tweaking related stuff.  The idea behind those
functionsis that we have our own specialised memset()-like macros.
 
MemoryContextAllocZeroAligned() uses MemSetLoop(), while
MemoryContextAllocZero() uses MemSetAligned().  Those date back nearly two decades and were apparently based on
experimentsdone at the time.
 
The comments talk about avoiding function call overhead and specialising for constant lengths, so I suppose we assumed
thatcompilers at the time didn't automatically know how to inline plain old memset() calls.
 

These days, you'd think you could add "assume aligned" attributes to all memory-allocation-like functions and then
changea few key things to be static inline so that the constants can be seen in the right places, and get all of the
samebenefits (and probably more) for free from the compiler's alignment analysis and inlining powers.
 

As for what benefits might actually be available, for constants it's clear but for alignment, I'm doubtful.  When Clang
8on amd64 inlines a memset() with a known aligned destination (for various alignment
 
sizes) and constant size, it generates a bunch of movups instructions, or with -march set to a modern arch, maybe
vmovups,and some variations depending on size.  Note 'u' (unaligned) instructions, not 'a' (aligned): that is, it
doesn'teven care that I said it the destination was aligned!  I found claims from a couple of Intel sources that this
sortof thing stopped making any difference to performance in the Nehalem microarchitecture (2008).  It still matters
whetherthe data actually is aligned, but not whether you use the instructions that tolerate misalignment, so there is
apparentlyno point in generating different code, and therefore, as far as memset() goes, apparently no gain from
annotatingallocation functions as returning aligned pointers.  As for other architectures or compilers, I don't know.
 

For curiosity, here's an experimental patch that gets rid of the
MemSetXXX() stuff, adds some (useless?) annotations about alignment and makes palloc0() and MemoryContextAllocZero()
inlineso that they can benefit from inlining with a visible constant size in eg newNode().  It didn't seem to do
anythingvery interesting apart from remove a few hundred lines of code, so I didn't get around to digging further or
sharingit earlier.  Or maybe I was just doing it wrong.
 
(In this patch it's using sizeof(long) which isn't enough to be considered aligned for the wider move instructions, but
Itried various sizes when trying to trigger different codegen, without success).
 


--
Thomas Munro
https://enterprisedb.com