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  (Pavan Deolasee <pavan.deolasee@gmail.com>)
Re: Autoanalyze and OldestXmin  (Jim Nasby <jim@nasby.net>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Error in PQsetvalue
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: SSI heap_insert and page-level predicate locks