Re: [HACKERS] Re: v7.1b4 bad performance
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Re: v7.1b4 bad performance |
Дата | |
Msg-id | 28149.982943591@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: v7.1b4 bad performance (Dmitry Morozovsky <marck@rinet.ru>) |
Ответы |
Re: [HACKERS] Re: v7.1b4 bad performance
RE: [HACKERS] Re: v7.1b4 bad performance |
Список | pgsql-admin |
Hannu Krosing <hannu@tm.ee> writes: > Is this unmodified pgbench or has it Hiroshi tweaked behaviour of > connecting each client to its own database, so that locking and such > does not shade the possible benefits (was it about 15% ?) of delay>1 I didn't much like that approach to altering the test, since it also means that all the clients are working with separate tables and hence not able to share read I/O; that doesn't seem like it's the same benchmark at all. What would make more sense to me is to increase the number of rows in the branches table. Right now, at the default "scale factor" of 1, pgbench makes tables of these sizes: accounts 100000 branches 1 history 0 (filled during test) tellers 10 It seems to me that the branches table should have at least 10 to 100 entries, and tellers about 10 times whatever branches is. 100000 accounts rows seems enough though. Making such a change would render results not comparable with the prior pgbench, but that would be true with Hiroshi's change too. Alternatively we could just say that we won't believe any numbers taken at scale factors less than, say, 10, but I doubt we really need million-row accounts tables in order to learn anything... regards, tom lane
В списке pgsql-admin по дате отправления: