On Tue, Aug 23, 2011 at 12:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I'm a bit concerned that this approach is trying to optimize the heavy
> contention situation at the cost of actually making things worse anytime
> that you're not bottlenecked by contention for access to this shared
> data structure. In particular, given the above design, then every
> reader of the data structure has to duplicate the work of eliminating
> subsequently-ended XIDs from the latest stored snapshot. Maybe that's
> relatively cheap, but if you do it N times it's not going to be so cheap
> anymore. In fact, it looks to me like that cost would scale about as
> O(N^2) in the number of transactions you allow to elapse before storing
> a new snapshot, so you're not going to be able to let very many go by
> before you do that.
That's certainly a fair concern, and it might even be worse than
O(n^2). On the other hand, the current approach involves scanning the
entire ProcArray for every snapshot, even if nothing has changed and
90% of the backends are sitting around playing tiddlywinks, so I don't
think I'm giving up something for nothing except perhaps in the case
where there is only one active backend in the entire system. On the
other hand, you could be entirely correct that the current
implementation wins in the uncontended case. Without testing it, I
just don't know...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
