Skip site navigation (1) Skip section navigation (2)

Re: pgstatindex

From: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pgstatindex
Date: 2002-05-28 01:07:46
Message-ID: 20020528.100746.98871902.t-ishii@sra.co.jp (view raw or flat)
Thread:
Lists: pgsql-hackers
> Oh.  Hmm, if that's what you want then I do not think an indexscan is
> the way to go about it.  The indexscan will only visit leaf pages
> (and not, for example, internal nodes of a btree).  Also the
> free-space-counting code you're using seems pretty unworkable since the
> indexscan is unlikely to visit leaf pages in anything like sequential
> order.

Oh I was not aware of this.

> I think the only reasonable way to get useful statistics would be to
> read the index directly --- page by page, no indexscan, distinguishing
> leaf pages, internal pages, and overhead pages for yourself.  This would
> require index-AM-specific knowledge about how to tell which type each
> page is, but I believe all the index AMs make that possible.

That's what I'm afraid of. 

> Also, I'd suggest that visiting the heap is just useless overhead.  A
> person who wants to know whether the heap needs to be vacuumed can get
> that data from pgstattuple.  Reading the heap to check tuple state will
> make this function orders of magnitude slower, while not producing much
> useful info that I can see.

Ok let me think about this. Thank you for the suggestion!
--
Tatsuo Ishii

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2002-05-28 01:16:59
Subject: Re: the parsing of parameters
Previous:From: Bruce MomjianDate: 2002-05-28 01:00:43
Subject: Re: [HACKERS] Re : Solaris Performance - 64 bit puzzle

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group