Re: pgstattuple extension for indexes - Mailing list pgsql-patches

From Bruce Momjian
Subject Re: pgstattuple extension for indexes
Date
Msg-id 200607060218.k662IKq25483@momjian.us
Whole thread Raw
In response to pgstattuple extension for indexes  (ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
Responses Re: pgstattuple extension for indexes
List pgsql-patches
Patch applied.  Thanks.

---------------------------------------------------------------------------


ITAGAKI Takahiro wrote:
> This is an extension of pgstattuple to query information from indexes.
> It supports btree, hash and gist. Gin is not supported.
> It scans only index pages and does not read corresponding heap tuples.
> Therefore, 'dead_tuple' means the number of tuples with LP_DELETE flag.
>
> Also, I added an experimental feature for btree indexes. It checks
> fragmentation factor of indexes. If an leaf has the right link on the next
> adjacent page in the file, it is assumed to be continuous (not fragmented).
> It will help us to decide when to REINDEX.
>
> Suggestions welcome.
>
> ----
> $ pgbench -i
> $ pgbench -n -t 100 -c 10
> # select * from pgstattuple('accounts_pkey');
> NOTICE:  0.36% fragmented
> HINT:  continuous=273, forward=1, backward=0
> -[ RECORD 1 ]------+--------
> table_len          | 2260992
> tuple_count        | 100996     -- 996 tuples are dead practically,
> tuple_len          | 1615936       but no LP_DELETE yet.
> tuple_percent      | 71.47
> dead_tuple_count   | 4
> dead_tuple_len     | 64         -- 64 tuples are marked as LP_DELETE.
> dead_tuple_percent | 0
> free_space         | 208188
> free_percent       | 9.21
> ----
>
>
> Regards,
> ---
> ITAGAKI Takahiro
> NTT Open Source Software Center

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster

--
  Bruce Momjian   bruce@momjian.us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Client build of MSVC6+ patch
Next
From: Andrew Dunstan
Date:
Subject: Re: Client build of MSVC6+ patch