Tom Lane wrote:
> Jeff Davis <pgsql@j-davis.com> writes:
> > With the new snapshot maintenance code, it looks like we can advance the
> > xmin more aggressively.
>
> The original design for that contemplated having snapmgr.c track
> all the snapshots (cf the comment for RegisteredSnapshots). I don't
> particularly care for having it assume that it can find all the resource
> owners.
>
> But really the more important problem is to demonstrate that you
> actually get a benefit commensurate with the additional cycles spent.
> IIRC the reason the code is the way it is is that we concluded that for
> typical usage patterns there wouldn't be any win from tracking things
> more aggressively. As somebody pointed out recently, SnapshotResetXmin
> is called quite a lot; if it's expensive it's going to be a problem.
I think Jeff is coming from the Truviso point of view: they have very
long running transactions, and they normally have a number of snapshots
that are always being updated, but it's rare that there are no snapshots
at all. So this optimization actually buys a chance to update Xmin at
all; with the current code, they keep the same xmin all the time because
there's always some snapshot.
I'm not sure if the best answer is to just state that Truviso should
keep maintaining this patch privately. It would be, of course, much
better to come up with a way to keep track of this in a cheaper way.
For example, maybe we could keep track of counts of snapshots removed
since the last xmin calculation, and only run this routine if the number
is different from zero (or some small positive integer).