From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
Cc: | josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Bitmap scans vs. the statistics views |
Date: | 2005-04-22 19:53:23 |
Message-ID: | 12334.1114199603@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
> tuples fetched is the number of raw, possibly dead tuples fetched from
> the heap. Tuples returned is the number of alive tuples ... IIRC.
No, count_heap_fetch only counts tuples that have already passed the
snapshot test. It could be that the places where the counts are
actually bumped don't line up with your original vision for the
stats design.
For a regular index scan, it seems to make sense to count (a) number of
TIDs returned by the index AM, and (b) number of tuples returned by the
IndexScan node. There are several intermediate steps
* does the tuple pass the snapshot test
* does the tuple pass any indexqual rechecks (for lossy indexes)
* does the tuple pass any additional non-index restriction
conditions that are being enforced at the scan level
but I'm not sure that counting all the intermediate steps is interesting.
The places where the counts are actually taken don't quite line up with
this ... there are also some other macros like count_heap_scan and
count_index_scan that seem a bit randomly placed. The description in
table 23-2 makes it sound like those should count once per scan, but
they are bumped inside the per-tuple loops ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-04-22 20:02:01 | Re: Bitmap scans vs. the statistics views |
Previous Message | Stephen Frost | 2005-04-22 19:47:35 | Re: Postgres: pg_hba.conf, md5, pg_shadow, encrypted passwords |