Re: profiling connection overhead

[Robert Haas <robertmhaas(at)gmail(dot)com>]

On Sun, Nov 28, 2010 at 11:51 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> Yeah, very true.  What's a bit frustrating about the whole thing is
>> that we spend a lot of time pulling data into the caches that's
>> basically static and never likely to change anywhere, ever.
>
> True.  I wonder if we could do something like the relcache init file
> for the catcaches.

Maybe.  It's hard to know exactly what to pull in, though, nor is it
clear to me how much it would really save.  You've got to keep the
thing up to date somehow, too.

I finally got around to doing some testing of
page-faults-versus-actually-memory-initialization, using the attached
test program, compiled with warnings, but without optimization.
Typical results on MacOS X:

first run: 297299
second run: 99653

And on Fedora 12 (2.6.32.23-170.fc12.x86_64):

first run: 509309
second run: 114721

I guess the word "run" is misleading (I wrote the program in 5
minutes); it's just zeroing the same chunk twice and measuring the
times.  The difference is presumably the page fault overhead, which
implies that faulting is two-thirds of the overhead on MacOS X and
three-quarters of the overhead on Linux.  This makes me pretty
pessimistic about the chances of a meaningful speedup here.

>> Maybe we could speed things up a bit if we got rid of the pg_attribute
>> entries for the system attributes (except OID).
>
> I used to have high hopes for that idea, but the column privileges
> patch broke it permanently.

http://archives.postgresql.org/pgsql-hackers/2010-07/msg00151.php

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Attachment: zero.c
Description: Text Data