Re: New to PostgreSQL, performance considerations - Mailing list pgsql-performance

From Ron
Subject Re: New to PostgreSQL, performance considerations
Date
Msg-id E1GwHT7-0006HH-FJ@elasmtp-spurfowl.atl.sa.earthlink.net
Whole thread Raw
In response to Re: New to PostgreSQL, performance considerations  (Michael Stone <mstone+postgres@mathom.us>)
List pgsql-performance
Sorry for the delay in responding.  I had familial obligations.

As a matter of fact, I am spending a decent amount of time on
this.  I don't usually pore through documentation for compilers and
OS's to the degree I've been since this thread started.  Nor do I
usually try and get access to the HW I'm presently tracking down.

I'll post my thoughts re: detailed analysis of gcc/g++ compiler
options later today or tomorrow as work schedule allows.

Why this is worth it:
1= Any gains from setup and configuration are the cheapest ones
available once we codify how to obtain them.
2= any public database or knowledge about how to best setup,
configure, and test pg is very good for the community.
3= developers need to know and agree on proper procedure and
technique for generating results for discussion or we end up wasting
a lot of time.
4= measuring and documenting pg performance means we know where best
to allocate resources for improving pg.  Or where using pg is
(in)appropriate compared to competitors.

Potential performance gains are not the only value of this thread.
Ron Peacetree


At 12:33 PM 12/16/2006, Michael Stone wrote:
>On Sat, Dec 16, 2006 at 10:53:21AM -0500, Ron wrote:
>>The most important "gain" IMO is Knowledge, and I'd say there is
>>still more to learn and/or verify IMHO. YMMV.
>
>Well, I think there are other areas where I can spend my time where
>potential gains are more likely. YMMV (although, I note, you don't
>seem to be spending much of your own time testing this)


pgsql-performance by date:

Previous
From: "Sabin Coanda"
Date:
Subject: transaction ID wrap limit
Next
From: Tom Lane
Date:
Subject: Re: transaction ID wrap limit