Re: profiling connection overhead

Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Sat, Nov 27, 2010 at 11:18 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> >> Not sure that information moves us forward. If the postmaster cleared
> >> the memory, we would have COW in the child and probably be even slower.
>
> > Well, we can determine the answers to these questions empirically.
>
> Not really. Per Bruce's description, a page would become COW the moment
> the postmaster touched (either write or read) any variable on it. Since
> we have no control over how the loader lays out static variables, the
> actual behavior of a particular build would be pretty random and subject
> to unexpected changes caused by seemingly unrelated edits.

I believe all linkers will put initialized data ("data" segment) before
unitialized data ("bss" segment):

http://en.wikipedia.org/wiki/Data_segment

The only question is whether the linker has data and bss sharing the
same VM page (4k), or whether a new VM page is used when starting the
bss segment.

> Also, the referenced URL only purports to describe the behavior of
> HPUX, which is not exactly a mainstream OS. I think it requires a
> considerable leap of faith to assume that all or even most platforms
> work the way this suggests, and not in the dumber fashion Andres
> suggested. Has anybody here actually looked at the relevant Linux
> or BSD kernel code?

I have years ago, but not recently. You can see the sections on Linux
via objdump:

$ objdump --headers /bin/ls

/bin/ls: file format elf32-i386

Sections:
Idx Name Size VMA LMA File off Algn
...
24 .data 0000012c 080611a0 080611a0 000191a0 2**5
CONTENTS, ALLOC, LOAD, DATA
25 .bss 00000c40 080612e0 080612e0 000192cc 2**5
ALLOC

Based on this output, a new 4k page is not started for the 'bss'
segment. It basically uses 32-byte alignment.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +