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
