From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: advance local xmin more aggressively |
Date: | 2009-02-11 16:40:08 |
Message-ID: | 1234370408.31945.43.camel@jdavis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 2009-02-11 at 10:20 -0500, Robert Haas wrote:
> On Tue, Feb 10, 2009 at 3:06 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> > With the new snapshot maintenance code, it looks like we can advance the
> > xmin more aggressively.
>
> Can you clarify the circumstances in which this patch would show a
> benefit over the current system?
In the current code, if the process is always holding at least one
snapshot, the process' xmin never advances. That means VACUUM will never
be able to reclaim tuples visible during the first snapshot taken during
the transaction.
With the patch, as long as snapshots are being released, the process'
xmin will keep advancing to reflect the oldest snapshot currently held
by that process.
In order to accomplish that, every time a snapshot is released I have to
look at every snapshot that the process still holds to find the new
local minimum xmin. The current code will only change the process' xmin
if there are no snapshots at all.
As Tom pointed out, one of the assumptions I made writing the patch is
not always true. I am still trying to determine the implications of
that.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-02-11 16:43:13 | Re: A deprecation policy |
Previous Message | Tom Lane | 2009-02-11 16:38:33 | Re: DISCARD ALL failing to acquire locks on pg_listen |