Re: Fork-based version of pgbench
От | Greg Stark |
---|---|
Тема | Re: Fork-based version of pgbench |
Дата | |
Msg-id | 87oe40f1dl.fsf@stark.xeocode.com обсуждение исходный текст |
Ответ на | Re: Fork-based version of pgbench (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Fork-based version of pgbench
|
Список | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.us> writes: > It's not so much that I want to inflate the measurements, as that > leaving 10% of the CPU on the table reduces pgbench's usefulness as > a way of stress-testing the backend. I suspect the difference is the same thing you theorised made the difference before. Namely that they're no longer proceeding in lockstep. The progress is more random allowing some processes to make more progress than average and benefit from better, er, well some cache somewhere. In any case it seems like there would be cases where each kind of behaviour would be useful. It seems likely there would be bugs where the lockstep behaviour was useful for testing, and other bugs where the randomized behaviour would be useful for testing too. -- greg
В списке pgsql-hackers по дате отправления: