From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Autoanalyze and OldestXmin |
Date: | 2011-06-08 15:33:35 |
Message-ID: | BANLkTi=J+7bNAsUr-obBuq6W_PBnfU0R=w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Jun 8, 2011 1:49 PM, "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> wrote:
>
>
> Hi All,
> There is a PROC_IN_ANALYZE flag, but we don't seem to be using it
anywhere. Since acquire_sample_rows() returns palloced tuples, can't we let
OldestXmin advance after scanning a page by ignoring procs with the flag
set, just like we do for PROC_IN_VACUUM ?
I don't even think the pallocing of tuples is a necessary condition. The key
requirement is that this process will not access any other tables in this
snapshot. In which case we don't need to take it into account when vacuuming
other tables.
It's not safe to vacuum tuples from the table being analyzed because the
vacuum could get ahead of the analyze.
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's possible to know that if
other tables are accessed they'll be with a brand new snapshot.
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2011-06-08 15:33:50 | Re: SSI heap_insert and page-level predicate locks |
Previous Message | Tom Lane | 2011-06-08 15:18:56 | Re: Error in PQsetvalue |