...and on Thu, Apr 22, 2004 at 06:59:10AM -0700, Eduardo Almeida used the keyboard:
snip
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
Folks,
Im doing the 100GB TPC-H and Ill 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
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,
Eduardo Almeida wrote:
Folks,
Im doing the 100GB TPC-H and Ill 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
...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_04
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 want
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
, 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 CREATE INDEX
several
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
Hi,
Has anyone had a look at:
http://people.ac.upc.es/zgomez/
I realize that MySQL PG cannot really be compared (especially when you
consider the issues that MySQL has with things like data integrity) but
still surely PG would perform better than the stats show (i.e. #7 31.28
seconds versus
On Wed, 2004-04-21 at 08:19, Rod Taylor wrote:
I realize that MySQL PG cannot really be compared (especially when you
consider the issues that MySQL has with things like data integrity) but
still surely PG would perform better than the stats show (i.e. #7 31.28
seconds versus 42
On 21/04/2004 09:31 Nick Barr wrote:
Hi,
Has anyone had a look at:
http://people.ac.upc.es/zgomez/
I realize that MySQL PG cannot really be compared (especially when you
consider the issues that MySQL has with things like data integrity) but
still surely PG would perform better than the
Looks like he's using the default postgresql.conf settings in which case
I'm not suprised at pg looking so slow.
The question also is, IMHO, why the hell, postgreSQL still comes out of the
box with so stupid configuration defaults, totally underestimated for todays
average hardware
On 21/04/2004 14:31 Cestmir Hybl wrote:
Looks like he's using the default postgresql.conf settings in which
case
I'm not suprised at pg looking so slow.
The question also is, IMHO, why the hell, postgreSQL still comes out of
the
box with so stupid configuration defaults, totally underestimated
Folks,
I've sent a polite e-mail to Mr. Gomez offering our help. Please, nobody
flame him!
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Paul Thomas wrote:
Looks like he's using the default postgresql.conf settings in which
case I'm not suprised at pg looking so slow. His stated use of foreign
keys invalidates the tests anyway as MyISAM tables don't support FKs
so we're probably seeing FK check overheads in pg that are simply
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
17 matches
Mail list logo
