Re: advance local xmin more aggressively
От | Tom Lane |
---|---|
Тема | Re: advance local xmin more aggressively |
Дата | |
Msg-id | 11226.1234372837@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: advance local xmin more aggressively (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: advance local xmin more aggressively
|
Список | pgsql-hackers |
Jeff Davis <pgsql@j-davis.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
В списке pgsql-hackers по дате отправления: