On Wed, 10 Dec 2008, Greg Smith wrote:
I'd be interested in recommendations for RAID cards for small SATA systems.
It's not anything to do with Postgres - I'm just intending to set up a
little four-drive array for my home computer, with cheap 1TB SATA drives.
Then why are you thinking of RAID
I would expect higher shared_buffers to raise the curve before the first
breakpoint but after the first breakpoint make the drop steeper and deeper.
The equilibrium where the curve becomes flatter should be lower.
On SpecJAppserver specifically, I remember seeing a drop when the
database size
Greg Stark wrote:
On Sun, Dec 7, 2008 at 7:38 PM, Josh Berkus wrote:
Also, the following patches currently still have bugs, but when the bugs are
fixed I'll be looking for performance testers, so please either watch the
wiki or watch this space:
...
-- posix_fadvise (Gregory Stark)
Eh? Quite
Tom,
Hmm ... I wonder whether this means that the current work on
parallelizing I/O (the posix_fadvise patch in particular) is a dead
end. Because what that is basically going to do is expend more CPU
to improve I/O efficiency. If you believe this thesis then that's
not the road we want to go
Scott Marlowe wrote:
involves tiny bits of data scattered throughout the database. Our
current database is about 20-25 Gig, which means it's quickly reaching
the point where it will not fit in our 32G of ram, and it's likely to
grow too big for 64Gig before a year or two is out.
...
I wonde
On Tue, 9 Dec 2008, Scott Carey wrote:
My system is now CPU bound, the I/O can do sequential reads of more than
1.2GB/sec but Postgres can't do a seqscan 30% as fast because it eats up
CPU like crazy just reading and identifying tuples... In addition to the
fadvise patch, postgres needs to mer
