From: | "Luke Lonergan" <llonergan(at)greenplum(dot)com> |
---|---|
To: | "Michael Stone" <mstone+postgres(at)mathom(dot)us>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: New to PostgreSQL, performance considerations |
Date: | 2006-12-11 20:09:09 |
Message-ID: | C1A2FAE5.154EF%llonergan@greenplum.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Stone | 2006-12-11 20:09:49 | Re: New to PostgreSQL, performance considerations |
Previous Message | Ron | 2006-12-11 20:08:02 | Re: New to PostgreSQL, performance considerations |