Re: pageinspect patch, for showing tuple data

From: Nikolay Shaplov <n(dot)shaplov(at)postgrespro(dot)ru>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Subject: Re: pageinspect patch, for showing tuple data
Date: 2015-10-02 11:19:41
Message-ID: 43752587.dn6APvuddE@nataraj-amd64
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

В письме от 2 октября 2015 13:10:22 пользователь Michael Paquier написал:

> >> + <para>
> >> + General idea about output columns: <function>lp_*</function>
> >> attributes
> >> + are about where tuple is located inside the page;
> >> + <function>t_xmin</function>, <function>t_xmax</function>,
> >> + <function>t_field3</function>, <function>t_ctid</function> are
>
> about
>
> >> + visibility of this tuplue inside or outside of the transaction;
> >> + <function>t_infomask2</function>, <function>t_infomask</function>
>
> has
>
> >> some
> >> + information about properties of attributes stored in tuple data.
> >> + <function>t_hoff</function> sais where tuple data begins and
> >> + <function>t_bits</function> sais which attributes are NULL and
>
> which
>
> >> are
> >> + not. Please notice that t_bits here is not an actual value that is
> >> stored
> >> + in tuple data, but it's text representation with '0' and '1'
> >> charactrs.
> >> + </para>
> >> I would remove that as well. htup_details.h contains all this
>
> information.
>
> > Made it even more shorter. Just links and comments about representation of
> > t_bits.
>
> I would completely remove this part.

Michael my hand would not do it. I've been working as a lecturer for six
years. If I want to pass an information in a comfortable way to reader, there
should go some binding phrase. It may be very vague, but it should outline
(may be in a very brief way, but still outline) an information that would be
found if he follows the links.

If we just give links "knowledge flow" will be uncomfortable for person who
reads it.

> -test=# SELECT * FROM heap_page_items(get_raw_page('pg_class', 0));
> +
> +test=# select * from heap_page_items(get_raw_page('pg_range', 0));
> This example in the docs is far too long in character length... We should
> get that reduced.

May be should do

\x and limit 1 like this:

test=# select * from heap_page_items(get_raw_page('pg_range', 0)) limit 1;
-[ RECORD 1 ]---------------------------------------------------
lp | 1
lp_off | 8144
lp_flags | 1
lp_len | 48
t_xmin | 1
t_xmax | 0
t_field3 | 0
t_ctid | (0,1)
t_infomask2 | 6
t_infomask | 2304
t_hoff | 24
t_bits |
t_oid |
t_data | \x400f00001700000000000000ba0700004a0f0000520f0000

????

> + Please notice that <function>t_bits</function> in tuple header
> structure
> + is a binary bitmap, but <function>heap_page_items</function> returns
> + <function>t_bits</function> as human readable text representation of
> + original <function>t_bits</function> bitmap.
> This had better remove the mention to "please notice". Still as this is
> already described in htup_details.h there is no real point to describe it
> again here: that's a bitmap of NULLs.

heap_page_items returns text(!) as t_bits. This is unexpected. This is not
described in page layout documentation. We should tell about it here
explicitly.

--
Nikolay Shaplov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2015-10-02 12:33:41 Re: In-core regression tests for replication, cascading, archiving, PITR, etc.
Previous Message Masahiko Sawada 2015-10-02 11:14:05 Re: Freeze avoidance of very large table.