Excerpts from Kevin Grittner's message of mar feb 22 20:29:26 -0300 2011: > Andrew Dunstan <and...@dunslane.net> wrote: > > > Have you performance tested it? Scanning pg_index for index > > columns for each row strikes me as likely to be unpleasant. > > I haven't, yet. I had rather assumed that the index info for a > relation would have a high probability of being cached during > execution of an AFTER trigger for that relation, so I think we're > talking RAM access here. It didn't seem sane to try to create an > HTAB for this and worry about invalidation of it, etc. If there's a > faster way to get to the info without going to such extremes, I'd be > happy to hear them. (At least I avoided building and parsing a > query to get at it.)
I think it'd be better to use RelationGetIndexList (which gets the index list from relcache) and fetch the index tuples from syscache; see relationHasPrimaryKey for sample code. -- Álvaro Herrera <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
