Michael, On 12/11/06 10:57 AM, "Michael Stone" <mstone+postgres@xxxxxxxxx> wrote: > That's kinda the opposite of what I meant by general code. I was trying > (perhaps poorly) to distinguish between scientific codes and other > stuff (especially I/O or human interface code). Yes - choice of language has often been a differentiator in these markets - LISP versus FORTRAN, C++ versus SQL/DBMS. This isn't just about science, it's also in Business Intelligence - e.g. Special purpose datamining code versus algorithms expressed inside a data management engine. > It also sounds like code specifically written to take advantage of > compiler techniques, rather than random code thrown at a pile of cflags. > I don't disagree that it is possible to get performance improvements if > code is written to be performant code; I do (and did) disagree with the > idea that you'll get huge performance improvements by taking regular old > C application code and playing with compiler flags. Agreed - that's my point exactly. > IMO that's appropriate for some science codes (although I think even > that sector is beginning to find that they've gone too far in a lot of > ways), but for a database I'd rather have people debugging clean, readable > code than risking my data to something incomprehensible that runs in > optimal time. Certainly something of a compromise is needed. >> Column databases like C-Store remove these abstractions at planner time to > > gcc --make-it-really-fast-by-rewriting-it-from-the-ground-up? Maybe not from ground->up, but rather from about 10,000 ft -> 25,000 ft? There are some who have done a lot of work studying the impact of more efficient DBMS, see here: http://homepages.cwi.nl/~boncz/x100.html - Luke
