Tom Lane wrote:
> Robert Haas <robertmhaas@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.)
Agreed. Doing something once and doing something in the sort loop are
two different overheads.
I am excited by this major speedup Peter Geoghegan has found. Postgres
doesn't have parallel query, which is often used for sorting, so we are
already behind some of the databases are compared against. Getting this
speedup is definitely going to help us. And I do like the generic
nature of where we are heading!
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +