Re: pgstatindex - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: pgstatindex
Date
Msg-id 20020528.100746.98871902.t-ishii@sra.co.jp
Whole thread Raw
In response to Re: pgstatindex  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [GENERAL] Re : Solaris Performance - 64 bit puzzle
Next
From: Bruce Momjian
Date:
Subject: Re: the parsing of parameters