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

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: Fwd: Re: [PERFORM] MySQL vs PG TPC-H benchmarks
Дата
Msg-id 6EE64EF3AB31D5448D0007DD34EEB34101ADC9@Herge.rcsinc.local
обсуждение исходный текст
Ответ на Fwd: Re: [PERFORM] MySQL vs PG TPC-H benchmarks  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: Fwd: Re: [PERFORM] MySQL vs PG TPC-H benchmarks  (Gavin Sherry <swm@linuxworld.com.au>)
Список 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 по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: [PERFORM] MySQL vs PG TPC-H benchmarks
Следующее
От: Jan Wieck
Дата:
Сообщение: Re: [PERFORM] MySQL vs PG TPC-H benchmarks