Re: What does this tell me?

From: "Josh Berkus" <josh(at)agliodbs(dot)com>
To: Joe Conway <mail(at)joeconway(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Sean Chittenden <sean(at)chittenden(dot)org>, pgsql-performance(at)postgresql(dot)org
Subject: Re: What does this tell me?
Date: 2002-10-09 05:22:37
Message-ID: web-1776618@davinci.ethosmedia.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Joe,

> If that's the case, can you split the work up into multiple
> functions, and execute them all from a shell script? Or perhaps even
> offload some of the data massaging to perl or something? (It would be
> easier to recommend alternate approaches with more details.)

I've already split it up into 11 functions, which are being managed
through Perl with ANALYZE statements between. Breaking it down
further would be really unmanageable.

Not to be mean or anything (after all, I just joined pgsql-advocacy),
I'm getting *much* worse performance on large data transformations from
PostgreSQL 7.2.1, than I get from SQL Server 7.0 on inferior hardware
(at least, except where SQL Server 7.0 crashes). I really am determined
to prove that it's because I've misconfigured it, and I thank all of
you for your help in doing so.

PGBench Results:
transaction type: TPC-B (sort of)
scaling factor: 10
number of clients: 100
number of transactions per client: 10
number of transactions actually processed: 1000/1000
tps = 93.206356(including connections establishing)
tps = 103.237007(excluding connections establishing)

Of course, I don't have much to compare these to, so I don't know if
that's good or bad.

-Josh Berkus

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Manfred Koizar 2002-10-09 08:00:03 Re: Large databases, performance
Previous Message Tom Lane 2002-10-09 05:22:26 Re: What does this tell me?