Re: Scaling SELECT:s with the number of disks on a stripe
От | Andrew - Supernews |
---|---|
Тема | Re: Scaling SELECT:s with the number of disks on a stripe |
Дата | |
Msg-id | slrnf17508.2i67.andrew+nonews@atlantis.supernews.net обсуждение исходный текст |
Ответ на | Scaling SELECT:s with the number of disks on a stripe (Peter Schuller <peter.schuller@infidyne.com>) |
Ответы |
Re: Scaling SELECT:s with the number of disks on a stripe
|
Список | pgsql-performance |
On 2007-04-04, Peter Schuller <peter.schuller@infidyne.com> wrote: >> The next question then is whether anything in your postgres configuration >> is preventing it getting useful performance from the OS. What settings >> have you changed in postgresql.conf? > > The only options not commented out are the following (it's not even > tweaked for buffer sizes and such, since in this case I am not > interested in things like sort performance and cache locality other > than as an afterthought): > > shared_buffers = 1000 I'd always do benchmarks with a realistic value of shared_buffers (i.e. much higher than that). Another thought that comes to mind is that the bitmap index scan does depend on the size of work_mem. Try increasing your shared_buffers to a reasonable working value (say 10%-15% of RAM - I was testing on a machine with 4GB of RAM, using a shared_buffers setting of 50000), and increase work_mem to 16364, and see if there are any noticable changes in behaviour. -- Andrew, Supernews http://www.supernews.com - individual and corporate NNTP services
В списке pgsql-performance по дате отправления: