Re: Inlining comparators as a performance optimisation
От | Pavel Stehule |
---|---|
Тема | Re: Inlining comparators as a performance optimisation |
Дата | |
Msg-id | CAFj8pRA5zqAi_dGS_UtwUMZfTb+zpRqUPKmDrFX+L6XSMnEi-Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Inlining comparators as a performance optimisation (Bruce Momjian <bruce@momjian.us>) |
Список | pgsql-hackers |
>> >> [ 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
В списке pgsql-hackers по дате отправления: