Re: LDC - Load Distributed Checkpoints with PG8.3b2 on Solaris - Mailing list pgsql-hackers

From Tom Lane
Subject Re: LDC - Load Distributed Checkpoints with PG8.3b2 on Solaris
Date
Msg-id 2182.1195139024@sss.pgh.pa.us
Whole thread Raw
In response to Re: LDC - Load Distributed Checkpoints with PG8.3b2 on Solaris  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: LDC - Load Distributed Checkpoints with PG8.3b2 on Solaris  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> Tom Lane wrote:
>> it seems like a serious omission that this gives you no hint how many
>> pages were scanned.

> Hmm, right.  I'm not sure how to fix it; the simplest idea is to count
> the number of heap page accesses in lazy_scan_heap, but this wouldn't
> count index pages so it wouldn't be real.  (However, we already report
> "index scans" so maybe this is not all that important).

> Another, more complex idea would be to use the already existing
> infrastructure for counting buffer accesses, as in ShowBufferUsage.
> However, just calling ResetBufferUsage and then get the counts would
> make the counters useless for the outer reporter (the callers in
> postgres.c).  We could have a separate set of "save" counters; so when
> vacuum starts, save the current counters and reset them; do the vacuum,
> report the counters; and finally, restore the save counters by adding
> the current counters.

> Is this too complex?

Too complex for my taste, anyway.  I would be satisfied if the log
entries just indicated how big the table and indexes were.  Heikki
pointed out that the message does tell you how many heap pages there
were, if you know to add removed + remain; but unless I'm still missing
something there's no way to tell how many index pages.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Trevor Talbot"
Date:
Subject: Re: Simplifying Text Search
Next
From: Tom Lane
Date:
Subject: Re: Simplifying Text Search