Re: can we optimize STACK_DEPTH_SLOP - Mailing list pgsql-hackers

From Greg Stark
Subject Re: can we optimize STACK_DEPTH_SLOP
Date
Msg-id CAM-w4HMiJKdjX=7SZj5OTtK7-VkznVbwsC1km=4X=Y0=0rej2w@mail.gmail.com
Whole thread Raw
In response to Re: can we optimize STACK_DEPTH_SLOP  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
Ok, I managed to get __atribute__((destructor)) working and capitured
the attached pmap output for all the revisions. You can see the git
revision in the binary name along with a putative date though in the
case of branches the date can be deceptive. It looks to me like REL8_4
is already bloated by REL8_4_0~2268 (which means 2268 commits *before*
the REL8_4_0 tag -- i.e. soon after it branched).

I can't really make heads or tails of this. I don't see any commits in
the early days of 8.4 that could change the stack depth in the
postmaster.

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: EXPLAIN ANALYZE for parallel query doesn't report the SortMethod information.
Next
From: Netanel Katzburg
Date:
Subject: Disable WAL completely - Performance and Persistency research