| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Re: Improvement of procArray.xmin for VACUUM |
| Date: | 2007-03-26 20:01:41 |
| Message-ID: | 200703262001.l2QK1fC27346@momjian.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
Simon Riggs wrote:
> On Sat, 2007-03-24 at 11:48 -0400, Tom Lane wrote:
>
> > 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"?
>
> Hmm, yes. How often do we have an LRT that consists of multiple
> statements of significant duration? Not often, I'd wager.
>
> How much does it cost to optimise for this case?
Zero cost. It involves just tracking if there are any old snapshots,
and if not, update the proc xmin rather than skipping the asignment,
like we do now.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2007-03-26 20:25:32 | Re: Improvement of procArray.xmin for VACUUM |
| Previous Message | Tom Lane | 2007-03-26 19:44:27 | Re: Improvement of procArray.xmin for VACUUM |