Re: [PATCH]pg_buffercache add a buffer state column, Add fuction to decode buffer state

From: Andres Freund <andres(at)anarazel(dot)de>
To: Moon Insung <Moon_Insung_i3(at)lab(dot)ntt(dot)co(dot)jp>
Cc: 'PostgreSQL Hackers' <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH]pg_buffercache add a buffer state column, Add fuction to decode buffer state
Date: 2017-11-14 09:06:53
Message-ID: 20171114090653.pxxnlhl6mpmgm7gr@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Arthur Zakirov 2017-11-14 09:25:47 Re: [HACKERS] pg_basebackup --progress output for batch execution
Previous Message Pavel Golub 2017-11-14 08:58:04 Re: Migration to PGLister - After