Re: PostgreSQL pre-fork speedup
От | Tom Lane |
---|---|
Тема | Re: PostgreSQL pre-fork speedup |
Дата | |
Msg-id | 2107.1083867090@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: PostgreSQL pre-fork speedup (sdv mailer <sdvmailer@yahoo.com>) |
Ответы |
Re: PostgreSQL pre-fork speedup
Re: PostgreSQL pre-fork speedup |
Список | pgsql-hackers |
sdv mailer <sdvmailer@yahoo.com> writes: > The point is pre-forking can *potentially* speed up > connections by 5x as shown in this simplistic > non-conclusive benchmark. I think this "benchmark" proves no such thing. The thing that pgpool is doing is not preforking connections at all, but re-using prior connections. The important difference is that you are using a "hot" backend that has already loaded a full working set of relcache and syscache entries --- and not just any old entries, but exactly those needed to process your query. (The fact that the pgbench test uses only a very limited set of queries probably causes this test to overstate the effect compared to more realistic workloads.) The profiling that I've done of backend startup shows that cache initialization accounts for the bulk of the startup delay. And IIRC, I was just measuring the time needed to be ready to accept the first query, not the additional effort to fetch query-specific cache entries. So having a hot backend would make a significant difference, but merely avoiding the fork wouldn't necessarily. regards, tom lane
В списке pgsql-hackers по дате отправления: