Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Just to answer the question (independently of Heikki's concern
> about whether this is needed at all): it depends on the
> information you have. If all you have is the index OID, then yeah
> a catcache lookup in pg_index is probably the best thing. If you
> have an open Relation for the index, you could instead look into
> its cached copy of its pg_index row. If you have an open Relation
> for the table, I'd think that looking for a match in
> RelationGetIndexList() would be the cheapest, since more than
> likely that information is already cached.
Thanks, I wasn't aware of RelationGetIndexList(). That's a good one
to remember.
The issue here was: given a particular heap relation, going through
a list of locks looking for matches, where the lock targets use
OIDs. So if I really *did* need to check whether an index was
related to that heap relation, it sounds like the catcache approach
would have been right. But as Heikki points out, the predicate
locks on the indexes only need to guard scanned *gaps* against
*insert* -- so a DROP TABLE or TRUNCATE TABLE can just skip looking
at any locks which aren't against the heap relation.
I think maybe I need a vacation -- you know, one where I'm not using
my vacation time to attend a PostgreSQL conference.
Thanks for the overview of what to use when; it takes a while, but I
think I'm gradually coming up to speed on the million lines of code
which comprise PostgreSQL. Tips like that do help.
-Kevin
