Re: Tuning PostgreSQL - Mailing list pgsql-performance

From Ron Johnson
Subject Re: Tuning PostgreSQL
Date
Msg-id 1059511115.7508.197.camel@haggis
Whole thread Raw
In response to Re: Tuning PostgreSQL  ("scott.marlowe" <scott.marlowe@ihs.com>)
Responses Re: Tuning PostgreSQL, pt 2
List pgsql-performance
On Tue, 2003-07-29 at 15:09, scott.marlowe wrote:
> On 29 Jul 2003, Ron Johnson wrote:
>
> > On Tue, 2003-07-29 at 14:00, scott.marlowe wrote:
> > > On 29 Jul 2003, Ron Johnson wrote:
> > >
> > > > On Tue, 2003-07-29 at 11:18, scott.marlowe wrote:
> > > > > On 29 Jul 2003, Ron Johnson wrote:
> > > > >
> > > > > > On Tue, 2003-07-29 at 10:14, Vivek Khera wrote:
> > > > > > > >>>>> "GS" == Greg Stark <gsstark@mit.edu> writes:
> > > > > > >
> > > > > > > GS> "scott.marlowe" <scott.marlowe@ihs.com> writes:
[snip]
> > > But that's seq scan.  For many database applications, random access
> > > performance is much more important.  Imagine 200 people entering
> > > reservations of 8k or less each into a transaction processing engine.
> > > Each transactions chance to hit an unoccupied spindle is what really
> > > counts.  If there's 30 spindles, each doing a stripe's worth of access all
> > > the time, it's likely to never flood the channel.
> > >
> > > If random access is 1/4th the speed of seq scan, then you need to multiply
> > > it by 4 to get the number of drives that'd saturate the PCI bus.
> >
> > Maybe it's just me, but I've never seen a purely TP system.
>
> I think most of them are running under TPF on a mainframe in a basement
> somewhere, like for airline reservations.  I've never worked on one, but
> met one of the guys who runs one, and they use 12 mainframes for 6 live
> machines and each live machine has a failover machine behind it in sysplex
> mode.  I kept thinking of the giant dinosaurs in Jurassic park...

We have something similar running on Alphas and VMS; does about
8M Txn/day.  Anyone who uses E-ZPass in the northeast eventually
gets stuck in our systems.

(Made me fear Big Brother...)

> > Even if roll off the daily updates to a "reporting database" each
> > night, some yahoo manager with enough juice to have his way still
> > wants up-to-the-minute reports...
>
> Just because it's TP doesn't mean it doesn't have real time reporting.
> But expensive reports probably do get run at night.

Yes, but...  There's always the exception.

> > Better yet, the Access Jockey, who thinks s/he's an SQL whiz but
> > couldn't JOIN himself out of a paper bag...
>
> I've seen a few who got joins and unions and what not, but explaining fks
> or transactions got me a glazed look... :-)

Wow!  They understood joins?  You lucky dog!!!

--
+-----------------------------------------------------------------+
| Ron Johnson, Jr.        Home: ron.l.johnson@cox.net             |
| Jefferson, LA  USA                                              |
|                                                                 |
| "I'm not a vegetarian because I love animals, I'm a vegetarian  |
|  because I hate vegetables!"                                    |
|    unknown                                                      |
+-----------------------------------------------------------------+



pgsql-performance by date:

Previous
From: "scott.marlowe"
Date:
Subject: Re: Tuning PostgreSQL
Next
From: Tom Lane
Date:
Subject: Re: Why performance improvement on converting subselect to a function ?