Re: Why the buildfarm is all pink

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Dec 10, 2013 at 7:55 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Anyway, bottom line is that I think we need to institute, and
>> back-patch, some consistent scheme for when to analyze the standard
>> tables during the regression tests, so that we don't have hazards
>> like this for tests that want to check what plan gets selected.
>>
>> Comments?

> Everything you're saying sounds reasonable from here.

I experimented with this and found out that an across-the-board ANALYZE
in the copy test causes a number of existing plan results to change,
because actually the very small tables like int4_tbl have never been
analyzed at all in the past. Now, that might be just fine, or it might
be that those tests would no longer test the code path they were meant
to test. I lack the energy right now to examine each one and decide
whether the change is OK. What I propose instead is that the copy test
only analyze the tables that it itself loaded. This lets us get rid
of most of the ad-hoc ANALYZEs of pre-existing tables, as in the attached
proposed patch against HEAD. I ended up leaving in the "vacuum analyze
tenk1" in create_index.sql, because it turns out what that is actually
accomplishing is to fill the visibility map so that an index-only scan
will be chosen. Maybe we should change all the added ANALYZEs in the
copy test to VACUUM ANALYZEs? That would be redundant though with the
database-wide VACUUM in sanity_check.sql, which unfortunately runs after
create_index.sql.

I haven't touched matview.sql here; that seems like a distinct issue.

regards, tom lane