Re: profiling connection overhead

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Subject: Re: profiling connection overhead
Date: 2010-11-28 20:45:18
Message-ID: 201011282045.oASKjIq04185@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas wrote:
> 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. I
> think some more scrutiny of the code with the points you and Andres
> and Tom have raised is probably in order, and probably some more
> benchmarking, too. I haven't had a chance to do that yet, however.

Basically, my bet is if you allocated a large zero-data variable in the
postmaster but never accessed it from the postmaster, at most you would
copy-on-write (COW) fault in two page, one at the beginning that is
shared by accessed variables, and one at the end. The remaining pages
(4k default for x86) would be zero-filled and not COW shared.

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

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-11-28 20:53:00 Re: profiling connection overhead
Previous Message Dimitri Fontaine 2010-11-28 20:02:56 Re: Rethinking representation of sort/hash semantics in queries and plans