On 1 December 2011 17:15, Robert Haas <robertmh...@gmail.com> wrote: > One thing I'm starting to get a bit concerned about is the effect of > this patch on the size of the resulting binary. The performance > results you've posted are getting steadily more impressive as you get > into this, which is cool, but it seems like the number of copies of > the qsort logic that you're proposing to include in the resulting > binary is also steadily climbing. On my system, a stripped postgres > binary built with my usual compile options (except --enable-cassert, > which I took out) is 49336 bytes bigger with this patch applied, an > increase of close to 1%.
Do your usual compile options include debug symbols? I've been using standard compile options for development of this patch, for obvious reasons. I get 36690 bytes (just under 36 KiB, or a 0.644% increase). Binary bloat is a legitimate concern. I thought that I was conservative in my choice of specialisations though. > We might need to be a little bit choosy > about this, because I don't think that we want to end up with a > situation where some noticeable percentage of the final binary > consists of differently-inlined versions of the quicksort algorithm - > especially because there may be other places where we want to do > similar kinds of inlining. > > Thoughts? A simple caveat in a comment along the lines of "this mechanism instantiates 2 copies of qsort_arg per type, please use judiciously" sounds like the right balance. It could also be possible to be penny wise and pound foolish here though. -- 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
