Re: Benchmark shows very slow bulk delete
От | James Mansion |
---|---|
Тема | Re: Benchmark shows very slow bulk delete |
Дата | |
Msg-id | 4B60ADD1.80005@mansionfamily.plus.com обсуждение исходный текст |
Ответ на | Re: Benchmark shows very slow bulk delete (Ivan Voras <ivoras@freebsd.org>) |
Ответы |
Re: Benchmark shows very slow bulk delete
|
Список | pgsql-performance |
Ivan Voras wrote: > I wish that, when people got the idea to run a simplistic benchmark > like this, they would at least have the common sense to put the > database on a RAM drive to avoid problems with different cylinder > speeds of rotational media and fragmentation from multiple runs. Huh? > It's tough to benchmark anything involving rotational drives :) But - how the database organises its IO to maximise the available bandwidth, limit avaiodable seeks, and limit avoidable flushes is absolutely key to realistic performance, especially on modest everyday hardware. Not everyone has a usage that justifies 'enterprise' kit - but plenty of people can benefit from something a step up from SQLite. If you just want to benchmark query processor efficiency then that's one scenario where taking physical IO out of the picture might be justified, but I don't see a good reason to suggest that it is 'common sense' to do so for all testing, and while the hardware involved is pretty low end, its still a valid data point. .
В списке pgsql-performance по дате отправления: