RE: [HACKERS][PATCH]pg_buffercache add a buffer state column, Add fuction to decode buffer state
| От | Moon Insung | 
|---|---|
| Тема | RE: [HACKERS][PATCH]pg_buffercache add a buffer state column, Add fuction to decode buffer state | 
| Дата | |
| Msg-id | 003101d35d2c$0d77b710$28672530$@lab.ntt.co.jp обсуждение исходный текст | 
| Ответы | Re: [HACKERS][PATCH]pg_buffercache add a buffer state column, Addfuction to decode buffer state | 
| Список | pgsql-hackers | 
# I add [hacker] to the mail subject.
Dear Andres Freund.
Thank you for review!
> 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.
Okay!
I'll not print(or add) the internal value directly.
(and I'll be careful when create another patch).
Thank you
> 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?
It's it better to output the decode state value from pg_buffercache view?
For example to following output
-----
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     | {LOCKED,VALID,TAG_VALID,PERMANENT}
-----
It's right?
If it is correct, I'll modify patch ASAP.
Regards.
Moon.
> -----Original Message-----
> From: Andres Freund [mailto:andres@anarazel.de]
> Sent: Tuesday, November 14, 2017 6:07 PM
> To: Moon Insung
> Cc: 'PostgreSQL Hackers'
> Subject: Re: [PATCH]pg_buffercache add a buffer state column, Add fuction to decode buffer state
> 
> 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 по дате отправления: