On Wed, Jun 15, 2016 at 1:29 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Jun 15, 2016 at 1:44 PM, Kevin Grittner <kgri...@gmail.com> > wrote:>> So what happens in this scenario: >>> 1. ANALYZE runs really slowly - maybe the user-defined function it's >>> running for the expression index is extremely long-running. >>> 2. Eventually, the snapshot for ANALYZE is older than the configured >>> value of snapshot_too_old. >>> 3. Then, ANALYZE selects a page with an LSN new enough that it might >>> have been pruned. >>> >>> Presumably, the ANALYZE ought to error out in this scenario, just as >>> it would in any other situation where an old snapshot sees a new page. >>> No? >> >> The test I showed creates a situation which (to ANALYZE) is >> identical to what you describe -- ANALYZE sees a page with an LSN >> recent enough that it could have been (and actually has been) >> pruned. Why would it be better for the ANALYZE to fail than to >> complete? > > As I understand it, the reason we need to sometimes give "ERROR: > snapshot too old" after early pruning is because we might otherwise > give the wrong answer. > > Maybe I'm confused.
In the scenario that you describe, ANALYZE is coming up with statistics to use in query planning, and the numbers are not expected to always be 100% accurate. I can think of conditions which might prevail when seeing the recent LSN. (1) The recent LSN is from a cause having nothing to do with the STO feature, like DML. As things stand, the behavior is the same as without the patch -- the rows are counted just the same as always. If we did as you suggest, we instead would abort ANALYZE and have stale statistics. (2) The recent LSN is related to STO pruning. The dead rows are gone forever, and will not be counted. This seems more correct than counting them, even if it were possible, and also superior to aborting the ANALYZE and leaving stale statistics. Of course, a subset of (1) is the case that the rows can be early-pruned at the next opportunity. In such a case ANALYZE is still counting them according to the rules that we had before the snapshot too old feature. If someone wants to argue that those rules are wrong, that seems like material for a separate patch. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
