Re: SSI performance

I wrote:
 
> I just had a thought -- we already have the LocalPredicateLockHash
> HTAB to help with granularity promotion issues without LW
> locking.  Offhand, I can't see any reason we couldn't use this for
> an initial check for a relation level lock, before going through
> the more rigorous pass under cover of the locks.  We won't have a
> relation lock showing in the local table if it never was taken
> out, and it won't go away until the end of transaction (unless the
> whole transaction is deamed safe from SSI conflicts and everything
> is cleaned up early).
>  
> Dan, does that look sane to you, or am I having another "senior
> moment" here?
>  
> If this works, it would be a very minor change, which might
> eliminate a lot of that overhead for many common cases.
 
To make this more concrete:
 
http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git;a=commitdiff;h=91d93734b8a84cf54e77f8d30b26afde7cc43218
 
I *think* we should be able to do this with the page lock level,
too; but I'd like Dan to weigh in on that before putting something
out there for that.  He did the local lock table work, and will be
in a better position to know how safe this is.  Also, while it's
pretty clear this should be a win at the relation level, it's not as
clear to me whether adding this for the page level will be a net
gain.
 
-Kevin