>> >> [ 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! >
Oracle has not or had not parallel sort too, and I have a reports so Oracle does sort faster then PostgreSQL (but without any numbers). So any solution is welcome Regards Pavel -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers