From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: advance local xmin more aggressively |
Date: | 2009-02-11 17:20:37 |
Message-ID: | 11226.1234372837@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> On Wed, 2009-02-11 at 10:20 -0500, Robert Haas wrote:
>> 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.
Right, and the question is the scope of the circumstances in which
that's the case and your patch makes things better. I believe that
* a process outside a transaction has no snapshots, so your patch
won't change anything
* a process in a serializable transaction will hold the serializable
snapshot till end of xact, so your patch won't change anything
* a process in a read-committed transaction will typically hold
snapshot(s) for the duration of each query, and then release them
all, so your patch won't change anything
You pointed out the case of opening a cursor in a read-committed
transaction, and then closing it before end of transaction, as a
place where your patch could hope to improve matters. Are there
others? Could your application be made to close that cursor before
opening another one (so that its set of open snapshots momentarily
goes to zero)? It seems like the use case for more complex
bookkeeping for open snapshots is a tad narrow.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2009-02-11 17:21:52 | Re: temporarily stop autovacuum |
Previous Message | Tom Lane | 2009-02-11 17:10:42 | Re: Optimization rules for semi and anti joins |