On Sat, 26 Jan 2002, Jean Huveneers wrote:
> And multi-processor usage depends on your linux kernel.
Or FreeBSD or anything else of course.
> But what is the best file system to use?
> I'm going to run postgres on a IDE-RAID5 (hardware from 3Ware) ATA-100
> system, total capacity around the 160
At 07:22 26.1.2002, Jean Huveneers wrote the following message:
>I'm going to run postgres on a IDE-RAID5 (hardware from 3Ware) ATA-100
Have you done any testing of RAID5 with IDE disks yet? There were reports
from people that RAID0 and RAID1 are screamingly fast with 3ware, but said
that thei
ECTED]]
Sent: Friday, January 25, 2002 7:24 AM
To: Radu-Adrian Popescu
Cc: Peter T. Brown; Postgres Admin List
Subject: Re: [ADMIN] Maximum Performance Follow-up Question
Radu-Adrian Popescu <[EMAIL PROTECTED]> writes:
> I belive you should set
> fsync=false
> in case you mainly sel
"Peter T. Brown" <[EMAIL PROTECTED]> writes:
> Is there any BIG risk in turning fsync off?
No, I wouldn't say so if you consider your data noncritical. fsync is
for stuff like orders and bank accounts, where losing even one
committed transaction is not acceptable.
> And isn't there some way to
Radu-Adrian Popescu <[EMAIL PROTECTED]> writes:
> I belive you should set
> fsync=false
> in case you mainly select and do inserts rather rare.
No, that's a really horrid reason to turn off fsync. A read-only
transaction never syncs and thus has no fsync penalty. If update
performance isn
On Thu, 2002-01-24 at 20:47, Peter T. Brown wrote:
> That helps a great deal! I am learning about the 'run-fast' option in
> postgres: Increasing the shared_buffers is critical. Here is a copy of my
> postgresql.conf file. I'll make the increases you suggested, but is there
> anything else you can
Related question regarding this config file and some other suggestions in this
thread. I have a similar configuration that I'm constantly tuning based on my
experience and comments I read in various places. So far, based on what I
"learned" these parameters would seem way to high for 1GB configura
Luis Amigo wrote:
> I would keep an eye on backend's mem usage, don't let them get out of memory
> nor go to swap.
> I would consider increasing wal_files, i think postmaster is telling you every
> minute
Actually, checkpoint_segments is the critical parameter when you have
lots of activity and a
ED]]
Sent: Thursday, January 24, 2002 10:24 AM
To: Peter T. Brown
Cc: 'Jean Huveneers'; [EMAIL PROTECTED]
Subject: Re: [ADMIN] Maximum Performance Follow-up Question
"Peter T. Brown" wrote:
> But how can Postgres be 'forced' to keep a table in memory? I've
I would keep an eye on backend's mem usage, don't let them get out of memory
nor go to swap.
I would consider increasing wal_files, i think postmaster is telling you every
minute
hope it helps
Regards
begin:vcard
n:Amigo Navarro;Luis Alberto
tel;cell:609581857
x-mozilla-html:FALSE
org:Universid
"Peter T. Brown" <[EMAIL PROTECTED]> writes:
> But how can Postgres be 'forced' to keep a table in memory? I've noticed
> that on our Dual Pentium4, 1GB RAM machine, the size of the individual
> postgres threads is very small. Top reports it as like 5K or 20K (I believe
> that's what it means). Sh
"Peter T. Brown" wrote:
> But how can Postgres be 'forced' to keep a table in memory? I've noticed
> that on our Dual Pentium4, 1GB RAM machine, the size of the individual
> postgres threads is very small. Top reports it as like 5K or 20K (I believe
> that's what it means). Shouldn't this number
nt: Thursday, January 24, 2002 12:27 AM
To: Jean Huveneers
Cc: [EMAIL PROTECTED]
Subject: Re: [ADMIN] Maximum Performance
Jean Huveneers wrote:
> Hi,
>
> Within an couple of weeks we will start using PostgreSQL on Mandrake 8.1
> in real business (we have been testing, for over a h
Jean,
We are using a quad pentium xeon machine with 6 GB ram RH 7.1 enterprise
kernel. Postgres uses everything that is available. Actually, its only
idling with the hardware we have and we have tables with over 2M rows.
Your disk subsystem is very important as well as it can easily become a
bottl
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
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.
>
On Thu, 2002-01-24 at 10:02, Jean Huveneers wrote:
> Hi,
>
> Within an couple of weeks we will start using PostgreSQL on Mandrake 8.1
> in real business (we have been testing, for over a half year).
>
Not that i have anything against Mandrake, but it is a desktop
distribution. I've heard several
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 pr
Jean Huveneers wrote:
> Hi,
>
> Within an couple of weeks we will start using PostgreSQL on Mandrake 8.1
> in real business (we have been testing, for over a half year).
>
> In future we will have some tables with 100.000+ records an the system
> has te work very fast.
>
> I know that speed of qu
19 matches
Mail list logo
