Re: MVCC catalog access

On 2013-06-20 10:58:59 -0400, Robert Haas wrote:
> On Thu, Jun 20, 2013 at 10:35 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> >> But I'm still on the fence about whether this is really a valid test.
> >
> > I think it shows that we need to be careful and do further performance
> > evaluations and/or alleviate the pain by making things cheaper (say, a
> > "ddl counter" in shared mem, allowing to cache snapshots for the
> > syscache). If that artificial test hadn't shown problems I'd have voted
> > for just going ahead and not worry further.
>
> I tried a general snapshot counter that rolls over every time any
> transaction commits, but that doesn't help much. It's a small
> improvement on general workloads, but it's not effective against this
> kind of hammering. A DDL counter would be a bit more expensive
> because we'd have to insert an additional branch into
> GetSnapshotData() while ProcArrayLock is held, but it might be
> tolerable.

I actually wasn't thinking of adding it at that level. More like just
not fetching a new snapshot in systable_* if a) the global ddl counter
hasn't been increased b) our transactions hasn't performed any
ddl. Instead use the one used the last time we fetched one for that
purpose.

The global ddl counter could be increased everytime we commit and the
commit has invalidations queued. The local one everytime we execute
local cache invalidation messages (i.e. around CommandCounterIncrement).

I think something roughly along those lines should be doable without
adding new overhead to global paths. Except maybe some check in
snapmgr.c for that new, longer living, snapshot.

> Do you have code for this (or some portion of it) already?

Nope, sorry.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services