Robert Haas <robertmh...@gmail.com> writes: > OK, but I think it's also going to cost you an extra syscache lookup, > no? You're going to have to check for this new support function > first, and then if you don't find it, you'll have to check for the > original one. I don't think there's any higher-level caching around > opfamilies to save our bacon here, is there?
[ shrug... ] If you are bothered by that, get off your duff and provide the function for your datatype. But it's certainly going to be in the noise for btree index usage, and I submit that query parsing/setup involves quite a lot of syscache lookups already. I think that as a performance objection, the above is nonsensical. (And I would also comment that your proposal with a handle is going to involve a table search that's at least as expensive as a syscache lookup.) regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers