Re: LDC - Load Distributed Checkpoints with PG8.3b2 on Solaris

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 11:46:02
Message-ID: 20071115114602.GA19014@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:

> > 2007-11-13 09:21:19.830 PST 9458 LOG: automatic vacuum of table
> > "specdb.public.txn_log_table": index scans: 1
> > pages: 11 removed, 105 remain
> > tuples: 3147 removed, 40 remain
> > system usage: CPU 0.11s/0.09u sec elapsed 6.02 sec
>
> 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?

--
Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4
"La tristeza es un muro entre dos jardines" (Khalil Gibran)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2007-11-15 13:01:58 Re: psql -f doesn't complain about directories
Previous Message Gregory Stark 2007-11-15 10:41:16 Re: Simplifying Text Search