Re: New to PostgreSQL, performance considerations

Michael,

On 12/11/06 10:57 AM, "Michael Stone" <mstone+postgres(at)mathom(dot)us> 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