Peter Geoghegan <peter(at)2ndquadrant(dot)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

In response to

• Re: Inlining comparators as a performance optimisation at 2011-12-05 17:10:05 from Peter Geoghegan

Responses

• Re: Inlining comparators as a performance optimisation at 2011-12-06 10:40:23 from Nicolas Barbier

pgsql-hackers by date

Next:	From: Peter Eisentraut	Date: 2011-12-05 17:56:47
	Subject: pgsql: plpython: Add SPI cursor support
Previous:	From: Tom Lane	Date: 2011-12-05 17:31:10
	Subject: Re: [PATCH] Caching for stable expressions with constant arguments v3