User-Agent: Microsoft-Entourage/11.2.5.060620
Date: Mon, 11 Dec 2006 12:09:09 -0800
Subject: Re: New to PostgreSQL, performance considerations
From: "Luke Lonergan" <llonergan@greenplum.com>
To: "Michael Stone" <mstone+postgres@mathom.us>,
	pgsql-performance@postgresql.org
Message-ID: <C1A2FAE5.154EF%llonergan@greenplum.com>
Thread-Topic: [PERFORM] New to PostgreSQL, performance considerations
Thread-Index: AccdYDeWdgoC5YlTEdu/8AAWy4o9DA==
In-Reply-To: <20061211185727.GJ16692@mathom.us>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=us-ascii
Content-Transfer-Encoding: 7bit

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