From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | "Jignesh K(dot) Shah" <J(dot)K(dot)Shah(at)Sun(dot)COM>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: LDC - Load Distributed Checkpoints with PG8.3b2 on Solaris |
Date: | 2007-11-15 15:03:44 |
Message-ID: | 2182.1195139024@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-11-15 15:13:41 | Re: Simplifying Text Search |
Previous Message | Trevor Talbot | 2007-11-15 14:20:45 | Re: Simplifying Text Search |