Re: Maximum Performance - Mailing list pgsql-admin

From Radu-Adrian Popescu
Subject Re: Maximum Performance
Date
Msg-id 1011870855.3343.49.camel@rpopescu
Whole thread Raw
In response to Maximum Performance  ("Jean Huveneers" <j.huveneers@farcourier.com>)
List pgsql-admin
On Thu, 2002-01-24 at 11:00, Manuel Trujillo wrote:
> El jue, 24-01-2002 a las 09:27, Luis Amigo escribió:
> > On my own experience I will tell you that if you're able to force postgres
> > to keep all database in memory it will be very fast, so memory only depends
> > on your
> > database size.
> > Each backend may run on a different processor, so the more processors u
> > have the more backends u can run at once
> > hope it helps
>
> Yes, but... How can I know the exact size of my database? And, if I
> compile the postgresql under four processors, don't work like (or in a)
> SMP, distributing the charge into the four processors??

First off, you could do a "du -h" in the data sub-directory in your
postgresql installation, to get an ideea about how large it is.

Even better, you could do a select count(*) from table1; and repeat this
in order to get the number of rows you have in each table in your
database. You can also get the size of a row in a table. Obviously, you
can multiply the n_rows with the row_width and get the approx. size of a
table. So there you go. But do add space for the indexes, the sequences
and the pg_ tables. This sould be more accurate, but for a gross (and
faster) estimation use "du -h ."

Hope that helps. Make sure the amount of shram you get thru your kernel
is enough, but not large enough to prevent everything else run :-)


--



Radu-Adrian Popescu
CSA, DBA, Programmer


pgsql-admin by date:

Previous
From: Radu-Adrian Popescu
Date:
Subject: Re: Maximum Performance
Next
From: "Vilson farias"
Date:
Subject: ERROR: cannot read block