Re: [PATCHES] Try again: S_LOCK reduced contentionh]

Поиск
Список
Период
Сортировка
От dg@illustra.com (David Gould)
Тема Re: [PATCHES] Try again: S_LOCK reduced contentionh]
Дата
Msg-id 9805110553.AA13005@hawk.illustra.com
обсуждение исходный текст
Ответ на Re: [PATCHES] Try again: S_LOCK reduced contentionh]  (Bruce Momjian <maillist@candle.pha.pa.us>)
Ответы Re: [HACKERS] Re: [PATCHES] Try again: S_LOCK reduced contentionh]  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [PATCHES] Try again: S_LOCK reduced contentionh]  (Bruce Momjian <maillist@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: t-ishii@sra.co.jp
Дата:
Сообщение: functional index
Следующее
От: Tak Woohyun
Дата:
Сообщение: Re: [HACKERS] Help me!!! Please