| От | Tom Lane |
|---|---|
| Тема | Re: TPC-R benchmarks |
| Дата | |
| Msg-id | 25270.1064853219@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: TPC-R benchmarks (Shridhar Daithankar <shridhar_daithankar@persistent.co.in>) |
| Список | pgsql-performance |
Shridhar Daithankar <shridhar_daithankar@persistent.co.in> writes:
> Also if you have fast disk drives, you can reduce random page cost to 2 or 1.5.
Note however that most of the people who have found smaller
random_page_cost to be helpful are in situations where most of their
data fits in RAM. Reducing the cost towards 1 simply reflects the fact
that there's no sequential-fetch advantage when grabbing data that's
already in RAM.
When benchmarking with data sets considerably larger than available
buffer cache, I rather doubt that small random_page_cost would be a good
idea. Still, you might as well experiment to see.
regards, tom lane
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера