Re: Intermittent regression test failures from index-only plan changes - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Intermittent regression test failures from index-only plan changes
Date
Msg-id 20120827131809.GA11088@momjian.us
Whole thread Raw
In response to Re: Intermittent regression test failures from index-only plan changes  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Intermittent regression test failures from index-only plan changes
List pgsql-hackers
On Fri, Jan 27, 2012 at 01:45:28PM -0500, Robert Haas wrote:
> On Sat, Jan 7, 2012 at 12:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> I feel like this is a trick question, but I'll ask anyway: Can't we
> >> just ignore ANALYZE?
> >
> > AFAICS, no.  ANALYZE will run user-defined code: not only user-supplied
> > stats collection functions, but user-defined index expressions.  We
> > cannot assume that none of that ever requires a snapshot.
> 
> The question is: Why would it matter if we expunged tuples from table
> A while ANALYZE was running on table B?   I guess the problem is that
> the index on B might involve a user-defined function which (under the
> covers) peeks at table A, possibly now seeing an inconsistent view of
> the database.
> 
> It's pretty unfortunate to have to cater to that situation, though,
> because most of the time an ANALYZE on table A is only going to look
> at table A and the system catalogs.  In fact, it wouldn't even be
> disastrous (in most cases) if we removed tuples from the table being
> analyzed - we're engaged in an inherently statistical process anyway,
> so who really cares if things change on us in medias res?
> 
> Could we easily detect the cases where user code is being run and
> ignore ANALYZE when none is?
> 
> A probably crazy idea is to add an option to vacuum that would cause
> it, upon discovering that it can't set PD_ALL_VISIBLE on a page
> because the global xmin is too old, to wait for all of the virtual
> transaction IDs who might not be able to see every tuple on the page.
> This would allow us to get into a state where all the PD_ALL_VISIBLE
> bits are known to be set.  But that seems a bit complex for something
> that we probably don't care about much outside of the regression
> tests.
> 
> If none of the above is feasible (and I suspect it isn't), we might
> just want to tweak the queries to do something that will preclude
> using an index-only scan, like including tableoid::regclass in the
> target list.

Was this addressed?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Statistics and selectivity estimation for ranges
Next
From: Amit Kapila
Date:
Subject: Re: [WIP] Performance Improvement by reducing WAL for Update Operation