Re: Fwd: Re: [PERFORM] MySQL vs PG TPC-H benchmarks

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: "Josh Berkus" <josh(at)agliodbs(dot)com>
Cc: <pgsql-advocacy(at)postgresql(dot)org>
Subject: Re: Fwd: Re: [PERFORM] MySQL vs PG TPC-H benchmarks
Date: 2004-04-21 18:51:34
Message-ID: 6EE64EF3AB31D5448D0007DD34EEB34101ADC9@Herge.rcsinc.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy


> Perhaps one of the advocay team will pick up the batton?
He is using COPY to load the data...I can't think of any earthly reason
why it takes > 1d to load 10gb data...probabaly all boils down to
default shared buffer setting. I don't even really consider this
'optimizing', just basic configuring to match the software to the
machine.

Also, the create table statements do not have primary/foreign key
definitions...from his comments on the results page it's not clear if
this is intentional...

If RI is set up properly it may explain why the results are off.
Perhaps the data generating app is not functioning properly in some way.
( this might explain the tpc errors as well ). The fact that his
results are not returning correct row count is setting off warning
bells. Most of the use cases are relatively simple joins, actually.
Maybe one of the key columns is all nulls, or some similar strangeness.

It would be useful to know if his server is I/O or cpu bound. My guess
is that the server swapping stuff all while...

Running ANALYZE after import can work wonders...or does it? I don't
usually use COPY to do the import. Perhaps create indexes/constraints
after import?

Some explains might be helpful. Still, shared buffers is the first
thing to look at. Maybe if I get around to it, I'll try the tpc-h out
here.

Merlin

Responses

Browse pgsql-advocacy by date

  From Date Subject
Next Message Jan Wieck 2004-04-21 19:38:47 Re: [PERFORM] MySQL vs PG TPC-H benchmarks
Previous Message Josh Berkus 2004-04-21 17:47:03 Re: [PERFORM] MySQL vs PG TPC-H benchmarks