On 07/19/2005-02:41PM, Oliver Crosby wrote:
>
> No queries in particular appear to be a problem.
That could mean they are ALL a problem. Let see some EXPLAIN ANAYZE
results just to rule it out.
> At the moment it's just one user,
With 1 user PostgreSQL will probobaly never beat MySQL
but wit
s.
>
I would think that would help SELECT If the spindle isn't busy writing
Transaction log it can be reading for your SELECTs.
You did say you were CPU bound though.
--
--------
Christopher Weimann
http://www.k12usa.com
On 01/28/2005-05:57PM, Alex Turner wrote:
> >
> > Your system A has the absolute worst case Raid 5, 3 drives. The more
> > drives you add to Raid 5 the better it gets but it will never beat Raid
> > 10. On top of it being the worst case, pg_xlog is not on a separate
> > spindle.
> >
>
> True for
On 01/28/2005-10:59AM, Alex Turner wrote:
> At this point I will interject a couple of benchmark numbers based on
> a new system we just configured as food for thought.
>
> System A (old system):
> Compaq Proliant Dual Pentium III 933 with Smart Array 5300, one RAID
> 1, one 3 Disk RAID 5 on 10k R
On 02/26/2004-11:16AM, Dror Matalon wrote:
> >
> > effective_cache_size changes no cache settings for postgresql, it simply
> > acts as a hint to the planner on about how much of the dataset your OS /
> > Kernel / Disk cache can hold.
>
> I understand that. The question is why have the OS, in t
On 02/26/2004-01:58PM, Dror Matalon wrote:
>
> Sigh.
>
Sigh, right back at you.
> which brings me back to my question why not make Freebsd use more of its
> memory for disk caching and then tell postgres about it.
>
Because you can't. It already uses ALL RAM that isn't in use for
something
On 01/23/2004-10:18AM, Joshua D. Drake wrote:
>
> XFS also has the interesting ability (although I have yet to test it)
> that will allow you
> to take a snapshot of the filesystem. Thus you can have filesystem level
> backups
> of the PGDATA directory that are consistent even though the databas
