Re: Fwd: Re: [PERFORM] MySQL vs PG TPC-H benchmarks - Mailing list pgsql-advocacy

From Merlin Moncure
Subject Re: Fwd: Re: [PERFORM] MySQL vs PG TPC-H benchmarks
Date
Msg-id 6EE64EF3AB31D5448D0007DD34EEB34101ADC9@Herge.rcsinc.local
Whole thread Raw
In response to Fwd: Re: [PERFORM] MySQL vs PG TPC-H benchmarks  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Fwd: Re: [PERFORM] MySQL vs PG TPC-H benchmarks
List 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

pgsql-advocacy by date:

Previous
From: Josh Berkus
Date:
Subject: Re: [PERFORM] MySQL vs PG TPC-H benchmarks
Next
From: Jan Wieck
Date:
Subject: Re: [PERFORM] MySQL vs PG TPC-H benchmarks