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
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? |