From: Luke Lonergan <llonergan@greenplum.com>
To: Michael Stone <mstone+postgres@mathom.us>
To: pgsql-performance@postgresql.org
Subject: Re: New to PostgreSQL, performance considerations
Date: Mon, 11 Dec 2006 12:09:09 -0800
Message-ID: <C1A2FAE5.154EF%llonergan@greenplum.com> (raw)
In-Reply-To: <20061211185727.GJ16692@mathom.us>
Michael,
On 12/11/06 10:57 AM, "Michael Stone" <mstone+postgres@mathom.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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: llonergan@greenplum.com, mstone+postgres@mathom.us
Subject: Re: New to PostgreSQL, performance considerations
In-Reply-To: <C1A2FAE5.154EF%llonergan@greenplum.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox