| 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. +
| 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 |