Re: Autoanalyze and OldestXmin - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Autoanalyze and OldestXmin
Date
Msg-id BANLkTi=J+7bNAsUr-obBuq6W_PBnfU0R=w@mail.gmail.com
Whole thread Raw
In response to Autoanalyze and OldestXmin  (Pavan Deolasee <pavan.deolasee@gmail.com>)
Responses Re: Autoanalyze and OldestXmin
Re: Autoanalyze and OldestXmin
List pgsql-hackers
<p><br /> On Jun 8, 2011 1:49 PM, "Pavan Deolasee" <<a
href="mailto:pavan.deolasee@gmail.com">pavan.deolasee@gmail.com</a>>wrote:<br /> ><br /> ><br /> > Hi
All,<br/> > There is a PROC_IN_ANALYZE flag, but we don't seem to be using it anywhere.  Since acquire_sample_rows()
returnspalloced tuples, can't we let OldestXmin advance after scanning a page by ignoring procs with the flag set, just
likewe do for PROC_IN_VACUUM ? <p>I don't even think the pallocing of tuples is a necessary condition. The key
requirementis that this process will not access any other tables in this snapshot. In which case we don't need to take
itinto account when vacuuming other tables.<p>It's not safe to vacuum tuples from the table being analyzed because the
vacuumcould get ahead of the analyze.<p>This is kind of like the other property it would be nice to know about
transactions:that they've locked all the tables they're going to lock. That would be sufficient but overly strong test.
It'spossible to know that if other tables are accessed they'll be with a brand new snapshot. 

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Error in PQsetvalue
Next
From: Alvaro Herrera
Date:
Subject: Re: SSI heap_insert and page-level predicate locks