Re: [PATCHES] Try again: S_LOCK reduced contentionh] - Mailing list pgsql-hackers
From | dg@illustra.com (David Gould) |
---|---|
Subject | Re: [PATCHES] Try again: S_LOCK reduced contentionh] |
Date | |
Msg-id | 9805110553.AA13005@hawk.illustra.com Whole thread Raw |
In response to | Re: [PATCHES] Try again: S_LOCK reduced contentionh] (Bruce Momjian <maillist@candle.pha.pa.us>) |
Responses |
Re: [HACKERS] Re: [PATCHES] Try again: S_LOCK reduced contentionh]
Re: [PATCHES] Try again: S_LOCK reduced contentionh] |
List | pgsql-hackers |
Bruce Momjian: > > > OK, here is my argument for inlining tas(). > David Gould: > > I am going out of town till Monday, so don't have time to give this > > the thoughtful response it deserves. I will get back to you on this as > > I am not quite convinced, but obviously in the face of this I need to > > explain my reasoning. > > Sure. I just know that the reduction from 0.28 to 0.08 was performed > one 0.01 at a time. See the MemSet() macro. I am sure you will hate it > too, but it did reduce the number of calls to memset() and reduced > wallclock execution time as measured from the client. This is always how micro-optimization goes, 1% and 2% gains here and there. I am very familiar with it. Anyhow, I am just back, and it occured to me to ask you for an exact reproducable test setup, so that I can run the same thing and play around with it a bit. I am not convinced by your result for a number of reasons, but rather than just make assertions or speculations, I think I should do a little data collection. Also, if you have any other cases that you believe useful to test with, I would be very happy to try those too. Have you done call graph profile for this, or just flat profiling? I think you may find the call graph (gprof) output revealing, although perhaps not on this particular topic... One last item, appropos start up time. Illustra uses what we call "Server Caching". Basically when a connect is terminated, the backend instead of exiting goes into a pool of idle servers. When next a connection comes in for the same database, instead of forking and initing a new server, we merely reuse the old one. This saves lots of startup time. However, there are some problems in practice so we might want to do something "like this only different". The idea that occurred to me is to have the postmaster "pre-spawn" some servers in each (configurable) database. These would run all the initialization and then just wait for a socket to be handed to them. The postmaster would during idle time replenish the pool of ready servers. I think this might have a lot more impact on startup time than turning things into macros... Thoughts? -dg David Gould dg@illustra.com 510.628.3783 or 510.305.9468 Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612 "Of course, someone who knows more about this will correct me if I'm wrong, and someone who knows less will correct me if I'm right." --David Palmer (palmer@tybalt.caltech.edu)
pgsql-hackers by date: