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 18:10:45 |
Message-ID: | AANLkTimfnzvahHYCVBNt4efDG0PZ+Feb5JUcuchG2mDt@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Nov 29, 2010 at 12:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> (On the last two machines I had to cut the array size to 256MB to avoid
> swapping.)
You weren't kidding about that "not so recent" part. :-)
>> This makes me pretty
>> pessimistic about the chances of a meaningful speedup here.
>
> Yeah, this is confirmation that what you are seeing in the original test
> is mostly about faulting pages in, not about the zeroing. I think it
> would still be interesting to revisit the micro-optimization of
> MemSet(), but it doesn't look like massive restructuring to avoid it
> altogether is going to be worthwhile.
Yep. I think that what we've established here is that starting new
processes all time time is just plain expensive, and we're going to
have to start fewer of them if we want to make a meaningful
improvement.
My impression is that the process startup overhead is even higher on
Windows, although I am not now nor have I ever been a Windows
programmer.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-11-29 18:15:52 | Re: PROPOSAL of xmlvalidate |
Previous Message | Tom Lane | 2010-11-29 18:10:07 | Re: profiling connection overhead |