Excerpts from Kevin Grittner's message of mar feb 22 20:29:26 -0300 2011:
> Andrew Dunstan <andrew@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 <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support