On Wed, Feb 08, 2012 at 01:33:30PM +0000, Peter Geoghegan wrote: > It doesn't necessarily matter if we increase the size of the postgres > binary by 10%, precisely because most of that is not going to be in > play from one instant to the next. I'm thinking, in particular, of > btree index specialisations, where it could make perfect sense to "go > crazy". You cannot have a reasonable discussion about such costs > without considering that they will perhaps never be paid, given any > plausible workload. That's why the percentage that the postgres binary > size has been shown to increase by really isn't pertinent at all. At > best, it's a weak proxy for such costs, assuming you don't have a > demonscene-like preoccupation with reducing binary size, and I don't > believe that we should.
When you start a binary, your executable is mapped to a file system binary, and you page-fault in the pages you need. Now, if your optimization was alone in its own 4k (x86) virtual pages, and you never called the functions, odds are you would not pay a penalty, aside from distribution penalty, and perhaps a small penalty if useful code was before and after your block. The sort code expansion, however, is done in-line, in the middle of the sort code, you are clearly are filling in 64-byte (x86) CPU cache lines with type-specific expansion code for every sort case, whether we use the code or not. Now, I don't think it is a big problem, and I think the speedup is worth it for common data types, but we can't say the cost is zero. Saying it another way, having a binary in your file system that you never call is not overhead except for storage, but in this case, the sort code expansion is inside critical functions we are already calling. Frankly, it is the cost that has kept use away from using such optimizations for a long time. I recently posted that the zero-cost optimizations are mostly completed for sort and COPY, and we have to start considering non-zero-cost optimizations --- sad, but true. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
