Re: profiling connection overhead

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Subject: Re: profiling connection overhead
Date: 2010-11-29 16:57:51
Message-ID: AANLkTimE1cot6_8fyPhc+ZK=gZsKwvkWVTY+ESp_6gty@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

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 Content-Type Size
zero.c text/x-csrc 699 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hamza Bin Sohail 2010-11-29 17:05:24 large page query
Previous Message Robert Haas 2010-11-29 16:51:52 Re: pg_execute_from_file review