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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
