Re: Autoanalyze and OldestXmin

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.

In response to

Responses

Browse pgsql-hackers by date

  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