Re: Benchmark - Mailing list pgsql-sql

From JanWieck@t-online.de (Jan Wieck)
Subject Re: Benchmark
Date
Msg-id 200006022058.WAA07767@hot.jw.home
Whole thread Raw
In response to Benchmark  ("Nikolaj Lundsgaard" <Nikolaj@konfus.dk>)
List pgsql-sql
Nikolaj Lundsgaard wrote:
> Is there anywhere I can find some benchmark test for postgres. The reason is that I want to use it for a site that
couldhave several simultanous users querying the database and I want to be sure that it is stable (and fast) enough to
handlethat kind of (ab)use.
 
   There   is   actually  no  (DB-independant)  benchmark  suite   publicly available.

>
> Also which is fastest ?
>
> 1. A query (using index of course) for a text in the database.
>
> or
>
> 2. Reading from a file on the harddisk.
>
>
> If the answer is 1 will the answer still be 1 if I do it several times (100.000+ a day)
   Since any DB access boils down somehow  to  file  access,  it   could  never  be  1 (as long as your solution
doesn'tneed to   sequentially  read  big  files  to  find  small   pieces   of   information).
 
   The  question  you  have  to  ask  is, what would happen in a   concurrent environment?  If  there's  at  least  one
writing   process, must the entire information be blocked from reading?
 
   Postgres uses MVCC (Multi Version  Concurrency  Control)  for   it. So no reader will ever be blocked by a writer -
itsimply   sees a snapshot of the entire data as it was when he executed   the first DML statement.
 
   If  you  have  total  static  data, that never changes during   uptime of your application, use flat  files  or
some higher   level file interface like GDB or MySQL.
 
   If you have data in motion, use a database.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #




pgsql-sql by date:

Previous
From: JanWieck@t-online.de (Jan Wieck)
Date:
Subject: Re: Deferral of primary key constraint
Next
From: Peter Eisentraut
Date:
Subject: Re: SQL'92 web resources