Re: [PATCH]pg_buffercache add a buffer state column, Add fuction todecode buffer state
От | Andres Freund |
---|---|
Тема | Re: [PATCH]pg_buffercache add a buffer state column, Add fuction todecode buffer state |
Дата | |
Msg-id | 20171114090653.pxxnlhl6mpmgm7gr@alap3.anarazel.de обсуждение исходный текст |
Ответ на | [PATCH]pg_buffercache add a buffer state column, Add fuction to decode buffer state ("Moon Insung" <Moon_Insung_i3@lab.ntt.co.jp>) |
Список | pgsql-hackers |
Hi, On 2017-11-14 17:57:00 +0900, Moon Insung wrote: > So I add a state column to pg_buffercache view so that I could print a value indicating the state of the buffer. > This is outpu as an unit32 type, and examples are shown below. > ----- > postgres=# select * from pg_buffercache where bufferid = 1; > -[ RECORD 1 ]----+----------- > bufferid | 1 > relfilenode | 1262 > reltablespace | 1664 > reldatabase | 0 > relforknumber | 0 > relblocknumber | 0 > isdirty | f > usagecount | 5 > pinning_backends | 0 > buffer_state | 2203320320 <- it's a new column > ----- I'm disinclined to exposing state that way. It's an internal representation that's not unlikely to change. Sure, pg_buffercache is more of a debugging / investigatory tool, but I nevertheless see no reason to expose it that way. If we shared those flags more in a manner like you did below: > 1 | 1262 | {LOCKED,VALID,TAG_VALID,PERMANENT} that'd be more acceptable. However doing that by default would have some performance downsides, because we'd need to create these arrays for every row. One way around that would be to create a buffer_state type that's returned by pg_buffercache and then only decoded when outputting. Doing that + having a cast to an array seems like it'd provide most of the needed functionality? Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: