Re: Autoanalyze and OldestXmin
От | Greg Stark |
---|---|
Тема | Re: Autoanalyze and OldestXmin |
Дата | |
Msg-id | BANLkTi=J+7bNAsUr-obBuq6W_PBnfU0R=w@mail.gmail.com обсуждение исходный текст |
Ответ на | Autoanalyze and OldestXmin (Pavan Deolasee <pavan.deolasee@gmail.com>) |
Ответы |
Re: Autoanalyze and OldestXmin
Re: Autoanalyze and OldestXmin |
Список | 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 по дате отправления: