Re: hardware performance and some more

От: Kasim Oztoprak
Тема: Re: hardware performance and some more
Дата: ,
Msg-id: BasiliX-1.1.0-10591403113f2132d7efe6c@sandal.saglik.gov.tr
(см: обсуждение, исходный текст)
Ответ на: hardware performance and some more  (Kasim Oztoprak)
Ответы: Re: hardware performance and some more  ("Shridhar Daithankar")
Re: hardware performance and some more  (Ron Johnson)
Список: pgsql-performance

Скрыть дерево обсуждения

hardware performance and some more  (Kasim Oztoprak, )
 Re: hardware performance and some more  ("Shridhar Daithankar", )
 Re: hardware performance and some more  (Kasim Oztoprak, )
  Re: hardware performance and some more  (Ron Johnson, )
 Re: hardware performance and some more  ("Roman Fail", )
 Re: hardware performance and some more  (Kasim Oztoprak, )
 Re: hardware performance and some more  (William Yu, )
  Re: hardware performance and some more  ("Shridhar Daithankar", )
 Re: hardware performance and some more  (Kasim Oztoprak, )
  Re: hardware performance and some more  ("Shridhar Daithankar", )
  Re: hardware performance and some more  (Ron Johnson, )
   Re: hardware performance and some more  (Josh Berkus, )
    Re: hardware performance and some more  (Ron Johnson, )
 Re: hardware performance and some more  (Kasim Oztoprak, )
  Re: hardware performance and some more  ("Shridhar Daithankar", )

On 24 Jul 2003 23:25 EEST you wrote:

> On Thu, 2003-07-24 at 13:25, Kasim Oztoprak wrote:
> > On 24 Jul 2003 17:08 EEST you wrote:
> >
> > > On 24 Jul 2003 at 15:54, Kasim Oztoprak wrote:
> [snip]
> >
> > we do not have memory problem or disk problems. as I have seen in the list the best way to
> > use disks are using raid 10 for data and raid 1 for os. we can put as much memory as
> > we require.
> >
> > now the question, if we have 100 searches per second and in each search if we need 30 sql
> > instruction, what will be the performance of the system in the order of time. Let us say
> > we have two machines described aove in a cluster.
>
> That's 3000 sql statements per second, 180 thousand per minute!!!!
> What the heck is this database doing!!!!!
>
> A quad-CPU Opteron sure is looking useful right about now...  Or
> an quad-CPU AlphaServer ES45 running Linux, if 4x Opterons aren't
> available.
>
> How complicated are each of these SELECT statements?

this is kind of directory assistance application. actually the select statements are not
very complex. the database contain 25 million subscriber records and the operators searches
for the subscriber numbers or addresses. there are not much update operations actually the
update ratio is approximately %0.1 .

i will use at least 4 machines each having 4 cpu with the speed of 2.8 ghz xeon processors.
and suitable memory capacity with it.

i hope it will overcome with this problem. any similar implementation?

>
> --
>  -----------------------------------------------------------------
> | Ron Johnson, Jr.        Home:              |
> | Jefferson, LA  USA                                              |
> |                                                                 |
> | "I'm not a vegetarian because I love animals, I'm a vegetarian  |
> |  because I hate vegetables!"                                    |
> |    unknown                                                      |
>  -----------------------------------------------------------------
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to 



В списке pgsql-performance по дате сообщения:

От: Franco Bruno Borghesi
Дата:
Сообщение: Re: index questions
От: "Mendola Gaetano"
Дата:
Сообщение: Wrong rows number expected