Re: Intermittent regression test failure from index-only scans patch

On Sun, Oct 9, 2011 at 06:34, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Oct 8, 2011, at 11:04 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> I'm inclined to fix this by changing the test to examine idx_tup_read
>>> not idx_tup_fetch.  Alternatively, we could have the test force
>>> enable_indexonlyscan off.  Thoughts?
>
>> No preference.
>
> I ended up doing it the second way (ie enable_indexonlyscan = off)
> because it turns out that pg_stat_user_tables doesn't have the
> idx_tup_read column --- we track that count per index, not per table.
> I could have complicated the test's stats queries some more, but it
> seemed quite not relevant to the goals of the test.
>
>> Should we have another counter for heap fetches avoided?  Seems like that could be useful to know.
>
> Hm.  I'm hesitant to add another per-table (or per index?) statistics
> counter because of the resultant bloat in the stats file.  But it
> wouldn't be a bad idea for somebody to take two steps back and rethink
> what we're counting in this area.  The current counter definitions are
> mostly backwards-compatible with pre-8.1 behavior, and it seems like the
> goalposts have moved enough that maybe it's time to break compatibility.

We certainly need *some* way to figure out if this has been used,
IMHO. So yeah, if the current way doesn't scale enough, we need to
think of some other way. But I'm not sure one more counter would
really bloat it that bad? OTOH, repeating that reasoning enough time
will eventually make it enough to care about...

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/