Re: Page replacement algorithm in buffer cache

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Page replacement algorithm in buffer cache
Дата
Msg-id 008e01ce3117$a5941fc0$f0bc5f40$@kapila@huawei.com
обсуждение исходный текст
Ответ на Re: Page replacement algorithm in buffer cache  (Greg Smith <greg@2ndQuadrant.com>)
Список pgsql-hackers
On Thursday, April 04, 2013 7:19 AM Greg Smith wrote:
> On 4/2/13 11:54 AM, Robert Haas wrote:
> > But, having said that, I still think the best idea is what Andres
> > proposed, which pretty much matches my own thoughts: the bgwriter
> > needs to populate the free list, so that buffer allocations don't
> have
> > to wait for linear scans of the buffer array.
> 
> I was hoping this one would make it to a full six years of being on the
> TODO list before it came up again, missed it by a few weeks.  The
> funniest part is that Amit even submitted a patch on this theme a few
> months ago without much feedback:
> http://www.postgresql.org/message-
> id/6C0B27F7206C9E4CA54AE035729E9C382852FF97@szxeml509-mbs
>   That stalled where a few things have, on a) needing more regression
> test workloads, and b) wondering just what the deal with large
> shared_buffers setting degrading performance was.

For "b)", below are links where it decreased due to large shared buffers.

http://www.postgresql.org/message-id/attachment/27489/Results.htm
http://www.postgresql.org/message-id/6C0B27F7206C9E4CA54AE035729E9C38285442C
5@szxeml509-mbx


As per my observation, it occur when I/O starts. The dip could be due to
fluctuation or may be due to some OS scheduling or it could be due to
Eviction of dirty pages sooner than it would otherwise.

I think the further investigation can be more meaningful if the results can
be taken by someone else other than me.

One idea to proceed in this line could be we start with this patch and then
based on results, do the further experiments to make it more useful.  

With Regards,
Amit Kapila.




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]
Следующее
От: Nicolas Barbier
Дата:
Сообщение: Re: Drastic performance loss in assert-enabled build in HEAD