...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
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
Ð ÐÑÐ, 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
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
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
...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_
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
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,
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 te
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
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
i
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]
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
> 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 configurati
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 stat
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 4
> 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 minutes!!!).
We know that PostgreSQL 7.5 will perfor
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
18 matches
Mail list logo
