From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Cédric Villemain <cedric(dot)villemain(dot)debian(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Intermittent regression test failure from index-only scans patch |
Date: | 2011-10-08 15:57:37 |
Message-ID: | 10942.1318089457@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
=?ISO-8859-1?Q?C=E9dric_Villemain?= <cedric(dot)villemain(dot)debian(at)gmail(dot)com> writes:
> 2011/10/8 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> 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 before the stats test runs, then an index-only scan will
>> happen, and bingo, no idx_tup_fetch increment (because indeed no heap
>> tuple was fetched).
>>
>> 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 preferences, but is it interesting to add a "vacuum freeze"
> somewhere and check expected result after index-only scan ? (for both
> idx_tup_read and idx_tup_fetch)
This test is only trying to make sure that the stats collection
machinery is working. I don't think that we should try to coerce things
so that it can check something as context-sensitive as whether an
index-only scan happened. It's too fragile already --- we've seen
non-reproducible failures here many times before.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2011-10-08 16:07:37 | Re: [v9.2] Fix Leaky View Problem |
Previous Message | Tom Lane | 2011-10-08 15:52:08 | Re: index-only scans |