On 21 September 2011 15:50, Tom Lane <t...@sss.pgh.pa.us> wrote: > Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes: >> I'm not against making things faster, it's just that I haven't seen >> solid evidence yet that this will help. Just provide a best-case test >> case for this that shows a huge improvement, and I'll shut up. If the >> improvement is only modest, then let's discuss how big it is and whether >> it's worth the code ugliness this causes.
Fair enough. > The other question that I'm going to be asking is whether it's not > possible to get most of the same improvement with a much smaller code > footprint. That's a reasonable question, and I hope to be able to come up with a good answer. > I continue to suspect that getting rid of the SQL function > impedance-match layer (myFunctionCall2Coll etc) would provide most of > whatever gain is to be had here, without nearly as large a cost in code > size and maintainability, and with the extra benefit that the speedup > would also be available to non-core datatypes. I'm fairly surprised that your view on that is mostly or entirely unchanged, even after I've demonstrated a considerable performance advantage from a macro-based qsort implementation over my OS vendor's c std lib qsort(), using an isolated test-case, that does not have anything to do with that impedance mismatch. I'm not sure why you doubt that the same thing is happening within tuplesort. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
