From: | Vivek Khera <khera(at)kcilink(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Urgent need of (paid) PostgreSQL support in New |
Date: | 2002-12-13 18:40:19 |
Message-ID: | x7lm2t69v0.fsf@onceler.kciLink.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
>>>>> "TL" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
TL> There are varying opinions about that. Some say "push PG's
TL> shared-buffers setting as high as you can make it". Some say "use a
TL> conservatively small shared-buffers setting and expect the kernel to use
TL> the rest of physical memory as kernel disk buffers". But both camps
I think that once your DB size gets big enough, there will be queries
that suck no matter what, because you have to scan through a boatload
of disk pages. Basically, once your working set size is bigger than
the shared buffer space, you're hosed. Making shared buffer space
bigger than 50% of RAM will suck, as Tom said. I used to do that, now
I have about 25-30% of RAM as shared bufs. It still sucks because the
data size is too big. I've got the fastest disks I can get, and split
the data across multiple spindles using RAID5 (yes, I could probably
get faster with RAID 1+0 or something, but it is too late for that
now...)
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: khera(at)kciLink(dot)com Rockville, MD +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Crawford | 2002-12-13 19:47:49 | Re: \dD Bug?? |
Previous Message | Tom Lane | 2002-12-13 18:23:50 | Re: INDEX suggestion needed |