Peter Geoghegan <pe...@2ndquadrant.com> writes: > Why the strong aversion to what I've done? I accept that it's ugly, > but is it really worth worrying about that sort of regression in > maintainability for something that was basically untouched since 2006, > and will probably remain untouched after this work concludes, whatever > happens?
Maintainability is only part of the issue --- though it's definitely one part, since this code has hardly gone "untouched since 2006", cf http://git.postgresql.org/gitweb/?p=postgresql.git;a=history;f=src/backend/utils/sort/tuplesort.c;hb=HEAD What is bothering me is that this approach is going to cause substantial bloat of the executable code, and such bloat has got distributed costs, which we don't have any really good way to measure but for sure micro-benchmarks addressing only sort speed aren't going to reveal them. Cache lines filled with sort code take cycles to flush and replace with something else. I think it's possibly reasonable to have inlined copies of qsort for a small number of datatypes, but it seems much less reasonable to have multiple copies per datatype in order to obtain progressively tinier micro-benchmark speedups. We need to figure out what the tradeoff against executable size really is, but so far it seems like you've been ignoring the fact that there is any such tradeoff at all. 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