On Tue, Mar 23, 2010 at 12:12 AM, Greg Smith wrote:
> Carlo Stonebanks wrote:
>
>> So, we have the hardware, we have the O/S - but I think our config leaves
>> much to be desired. Typically, our planner makes nad decisions, picking seq
>> scan over index scan, where index scan has a better result
Carlo Stonebanks wrote:
So, we have the hardware, we have the O/S - but I think our config
leaves much to be desired. Typically, our planner makes nad decisions,
picking seq scan over index scan, where index scan has a better result.
You're not setting effective_cache_size, so I wouldn't exp
On 3/22/10 4:36 PM, Carlo Stonebanks wrote:
Here we go again!
Can anyone see any obvious faults?
Carlo
maintenance_work_mem = 256MB
I'm not sure how large your individual tables are, but you might want to
bump this value up to get faster vacuums.
max_fsm_relations = 1000
I think this will d
Here we go again!
Based on recommendations made here, I got my client to migrate off of our
Windows 2003 Server x64 box to a new Linux box.
# CENTOS 5.4
# Linux mdx_octo 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64
x86_64 x86_64 GNU/Linux
# pgsql 8.3.10, 8 CPUs, 48GB RAM
# RAID 1
