Skip site navigation (1) Skip section navigation (2)

Re: Large databases, performance

From: "Shridhar Daithankar" <shridhar_daithankar(at)persistent(dot)co(dot)in>
To: pgsql-hackers(at)postgresql(dot)org,pgsql-general <pgsql-general(at)postgresql(dot)org>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Large databases, performance
Date: 2002-10-07 09:37:29
Message-ID: 3DA1A331.21316.F7E742B@localhost (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackerspgsql-performancepgsql-sql
On 3 Oct 2002 at 8:54, Charles H. Woloszynski wrote:

> I'd be curious what happens when you submit more queries than you have 
> processors (you had four concurrent queries and four CPUs), if you care 
> to run any additional tests.  Also, I'd report the query time in 
> absolute (like you did) and also in 'Time/number of concurrent queries". 
>  This will give you a sense of how the system is scaling as the workload 
> increases.  Personally I am more concerned about this aspect than the 
> load time, since I am going to guess that this is where all the time is 
> spent.  

OK. I am back from my cave after some more tests are done. Here are the 
results. I am not repeating large part of it but answering your questions..

Don't ask me how these numbers changed. I am not the person who conducts the 
test neither I have access to the system. Rest(or most ) of the things remains 
same..

MySQL 3.23.52 with innodb transaction support: 

4 concurrent queries 	:-  257.36 ms
40 concurrent queries	:-  35.12 ms

Postgresql 7.2.2 

4 concurrent queries 		:- 257.43 ms
40 concurrent 	queries		:- 41.16 ms

Though I can not report oracle numbers, suffice to say that they fall in 
between these two numbers.

Oracle seems to be hell lot faster than mysql/postgresql to load raw data even 
when it's installed on reiserfs. We plan to run XFS tests later in hope that 
that would improve mysql/postgresql load times. 

In this run postgresql has better load time than mysql/innodb ( 18270 sec v/s 
17031 sec.) Index creation times are faster as well (100 sec v/s 130 sec). 
Don't know what parameters are changed.

Only worry is database size. Postgresql is 111GB v/s 87 GB for mysql. All 
numbers include indexes. This is really going to be a problem when things are 
deployed. Any idea how can it be taken down? 

WAL is out, it's not counted.

Schema optimisation is later issue. Right now all three databases are using 
same schema..

Will it help in this situation if I recompile posgresql with block size say 32K 
rather than 8K default? Will it saev some overhead and offer better performance 
in data load etc?

Will keep you guys updated..

Regards,
 Shridhar

-----------------------------------------------------------
Shridhar Daithankar
LIMS CPE Team Member, PSPL.
mailto:shridhar_daithankar(at)persistent(dot)co(dot)in
Phone:- +91-20-5678900 Extn.270
Fax  :- +91-20-5678901 
-----------------------------------------------------------


In response to

Responses

pgsql-performance by date

Next:From: Hans-Jürgen SchönigDate: 2002-10-07 10:01:32
Subject: Re: [pgsql-performance] Large databases, performance
Previous:From: Tom LaneDate: 2002-10-07 03:20:33
Subject: cross-posts (was Re: Large databases, performance)

pgsql-hackers by date

Next:From: Hans-Jürgen SchönigDate: 2002-10-07 10:01:32
Subject: Re: [pgsql-performance] Large databases, performance
Previous:From: Zeugswetter Andreas SB SDDate: 2002-10-07 08:42:44
Subject: Re: Proposed LogWriter Scheme, WAS: Potential Large Performance Gain in WAL synching

pgsql-sql by date

Next:From: Hans-Jürgen SchönigDate: 2002-10-07 10:01:32
Subject: Re: [pgsql-performance] Large databases, performance
Previous:From: Tom LaneDate: 2002-10-07 03:20:33
Subject: cross-posts (was Re: Large databases, performance)

pgsql-general by date

Next:From: Hans-Jürgen SchönigDate: 2002-10-07 10:01:32
Subject: Re: [pgsql-performance] Large databases, performance
Previous:From: Pavel StehuleDate: 2002-10-07 09:17:28
Subject: problem with composed types in plpgsql

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group