Re: Fix pg_buffercache document
От | Amit Kapila |
---|---|
Тема | Re: Fix pg_buffercache document |
Дата | |
Msg-id | CAA4eK1JH7EXR5M7CKYbjoOoygAUGyt7cfkKC89C=rYo-guZyNA@mail.gmail.com обсуждение исходный текст |
Ответ на | Fix pg_buffercache document (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>) |
Ответы |
Re: Fix pg_buffercache document
|
Список | pgsql-hackers |
On Thu, May 7, 2020 at 2:23 PM Masahiko Sawada <masahiko.sawada@2ndquadrant.com> wrote: > > Hi, > > The following description in pg_buffercace is no longer true. > > When the pg_buffercache view is accessed, internal buffer manager > locks are taken for long enough to copy all the buffer state data that > the view will display. This ensures that the view produces a > consistent set of results, while not blocking normal buffer activity > longer than necessary. Nonetheless there could be some impact on > database performance if this view is read often. > > We changed pg_buffercache_page so that it doesn't take buffer manager > locks in commit 6e654546fb6. Therefore from version 10, > pg_buffercache_page has less impact on normal buffer activity less but > might not return a consistent snapshot across all buffers instead. > +1. There is a typo in the patch (queris/queries). How about if slightly reword it as "Since buffer manager locks are not taken to copy the buffer state data that the view will display, accessing <structname>pg_buffercache</structname> view has less impact on normal buffer activity but it doesn't provide a consistent set of results across all buffers. However, we ensure that the information of each buffer is self-consistent."? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: