> 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
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!
In response to
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 2002-05-28 01:16:59|
|Subject: Re: the parsing of parameters|
|Previous:||From: Bruce Momjian||Date: 2002-05-28 01:00:43|
|Subject: Re: [HACKERS] Re : Solaris Performance - 64 bit puzzle|