Magnus Hagander writes:
> On Sun, Oct 9, 2011 at 06:34, Tom Lane wrote:
>> Robert Haas writes:
>>> 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
On Sun, Oct 9, 2011 at 06:34, Tom Lane wrote:
> Robert Haas writes:
>> On Oct 8, 2011, at 11:04 AM, Tom Lane 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. Thought
Robert Haas writes:
> On Oct 8, 2011, at 11:04 AM, Tom Lane 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
On Oct 8, 2011, at 11:04 AM, Tom Lane 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.
Should we have another counter for heap fetches avoided? S
=?ISO-8859-1?Q?C=E9dric_Villemain?= writes:
> 2011/10/8 Tom Lane :
>> The diff indicates that the idx_scan count advanced but idx_tup_fetch
>> did not, which is not so surprising here because tenk2 hasn't been
>> modified in some time. If the autovacuum daemon managed to mark it
>> all-visible be
2011/10/8 Tom Lane :
> I notice that several members of the buildfarm have been consistently
> showing the same regression test failure since the index-only scans
> patch went in:
>
> ***
> /home/pgbuildfarm/workdir/HEAD/pgsql.27150/src/test/regress/expected/stats.out
> Sat Oct 8 03:20:05 2
