Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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>

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

In response to

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group