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

2004-05-06 Thread Grega Bremec
...and on Thu, Apr 22, 2004 at 06:59:10AM -0700, Eduardo Almeida used the keyboard: > > To reference, Sun has java 64bits just to IA64 and > Solaris Sparc 64 not to Opteron. > As I mentioned, that is true for the 1.4.x release of the JVMs. We have been testing some JCA builds of 1.5.0 on x86_64

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

2004-04-22 Thread Eduardo Almeida
Folks, I forgot to mention that I used Shell scripts to load the data and use Java just to run the refresh functions. Talking about sort_mem config, I used 65000 but in the TPCH specification they said that you are not able to change the configs when you start the benchmark, is that a big problem

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

2004-04-22 Thread Markus Bertheau
Ð ÐÑÐ, 22.04.2004, Ð 17:54, Tom Lane ÐÐÑÐÑ: > Eduardo Almeida <[EMAIL PROTECTED]> writes: > > About 7hs:30min to load the data and 16:09:25 to > > create the indexes > > You could probably improve the index-create time by temporarily > increasing sort_mem. It wouldn't be unreasonable to give CREA

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

2004-04-22 Thread Tom Lane
Markus Bertheau <[EMAIL PROTECTED]> writes: >> You could probably improve the index-create time by temporarily >> increasing sort_mem. It wouldn't be unreasonable to give CREATE INDEX >> several hundred meg to work in. (You don't want sort_mem that big >> normally, because there may be many sorts

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

2004-04-22 Thread Tom Lane
Eduardo Almeida <[EMAIL PROTECTED]> writes: > About 7hs:30min to load the data and 16:09:25 to > create the indexes You could probably improve the index-create time by temporarily increasing sort_mem. It wouldn't be unreasonable to give CREATE INDEX several hundred meg to work in. (You don't wan

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

2004-04-22 Thread Grega Bremec
...and on Thu, Apr 22, 2004 at 05:53:18AM -0700, Eduardo Almeida used the keyboard: > > - The configuration of the machine is: > Dual opteron 64 bits model 240 > 4GB RAM > 960 GB on RAID 0 > Mandrake Linux 64 with Kernel 2.6.5 (I compiled a > kernel for this test) > Java SDK java version "1.4.2_

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

2004-04-22 Thread Jan Wieck
Eduardo Almeida wrote: Folks, I’m doing the 100GB TPC-H and I’ll show the previous results to our community (Postgres) in 3 weeks before finishing the study. My intention is to carry through a test with a VLDB in a low cost platform (PostgreSQL, Linux and cheap HW) and not to compare with another

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

2004-04-22 Thread Eduardo Almeida
Grega, That´s why I used java 32bits and needed to compile the kernel 2.6.5 with the 32bits modules. To reference, Sun has java 64bits just to IA64 and Solaris Sparc 64 not to Opteron. regards, Eduardo --- Grega Bremec <[EMAIL PROTECTED]> wrote: > ...and on Thu, Apr 22, 2004 at 05:53:18AM -0700,

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

2004-04-22 Thread Eduardo Almeida
Folks, I’m doing the 100GB TPC-H and I’ll show the previous results to our community (Postgres) in 3 weeks before finishing the study. My intention is to carry through a test with a VLDB in a low cost platform (PostgreSQL, Linux and cheap HW) and not to compare with another DBMS. So far I can te

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

2004-04-21 Thread Jan Wieck
Josh Berkus wrote: Folks, I've sent a polite e-mail to Mr. Gomez offering our help. Please, nobody flame him! Please keep in mind that the entire test has, other than a similar database schema and query types maybe, nothing to do with a TPC-H. I don't see any kind of SUT. Foreign key support