Re: Slow count(*) again...
| От | Samuel Gendler |
|---|---|
| Тема | Re: Slow count(*) again... |
| Дата | |
| Msg-id | AANLkTi=WE-CsGVC3j4CX9ddGGsRZ3Mmk6aJGKk4NT=g6@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Slow count(*) again... (Greg Smith <greg@2ndquadrant.com>) |
| Ответы |
Re: Slow count(*) again...
Re: Slow count(*) again... |
| Список | pgsql-performance |
On Mon, Oct 11, 2010 at 7:19 PM, Greg Smith <greg@2ndquadrant.com> wrote:
This is a problem for the operating system to solve, and such solutions out there are already good enough that PostgreSQL has little reason to try and innovate in this area. I routinely see seq scan throughput double on Linux just by tweaking read-ahead from the tiny defaults to a sane value.
I spent some time going through the various tuning docs on the wiki whie bringing some new hardware up and I can't remember seeing any discussion of tweaking read-ahead at all in the normal performance-tuning references. Do you have any documentation of the kinds of tweaking you have done and its effects on different types of workloads?
В списке pgsql-performance по дате отправления: