Re: Improvement of procArray.xmin for VACUUM
От | Tom Lane |
---|---|
Тема | Re: Improvement of procArray.xmin for VACUUM |
Дата | |
Msg-id | 5948.1174751302@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Improvement of procArray.xmin for VACUUM (Heikki Linnakangas <heikki@enterprisedb.com>) |
Ответы |
Re: Improvement of procArray.xmin for VACUUM
Re: Improvement of procArray.xmin for VACUUM Re: Improvement of procArray.xmin for VACUUM |
Список | pgsql-patches |
Heikki Linnakangas <heikki@enterprisedb.com> writes: > It seems to me a lot cleaner to do the reference counting like Tom > suggested. Increase the refcount on CopySnapshot, and decrease it on > FreeSnapshot. Assuming that all callers of CopySnapshot free the > snapshot with FreeSnapshot when they're done with it. I don't believe we bother at the moment; which is one of the reasons it'd be a nontrivial patch. I do think it might be worth doing though. In the simple case where you're just issuing successive non-cursor commands within a READ COMMITTED transaction, a refcounted implementation would be able to recognize that there are *no* live snapshots between commands and therefore reset MyProc->xmin to 0 whenever the backend is idle. OTOH, do we have any evidence that this is worth bothering with at all? I fear that the cases of long-running transactions that are problems in the real world wouldn't be helped much --- for instance, pg_dump wouldn't change behavior because it uses a serializable transaction. Also, at some point a long-running transaction becomes a bottleneck simply because its XID is itself the oldest thing visible in the ProcArray and is determining everyone's xmin. How much daylight is there really between "your xmin is old" and "your xid is old"? regards, tom lane
В списке pgsql-patches по дате отправления: