Greg Smith wrote:
Joseph S wrote:
Greg Smith wrote:
Joseph S wrote:
So I run "select count(*) from large_table" and I see in xosview a
solid block of write activity. Runtime is 28125.644 ms for the first
run. The second run does not show a block of write activity and
takes 3
Greg Smith wrote:
Joseph S wrote:
So I run "select count(*) from large_table" and I see in xosview a
solid block of write activity. Runtime is 28125.644 ms for the first
run. The second run does not show a block of write activity and takes
3327.441 ms
http://wiki.postgresq
I just installed a shiny new database server with pg 8.4.1 running on
CentOS 5.4. After using slony to replicate over my database I decided to
do some basic performance tests to see how spiffy my shiny new server
is. This machine has 32G ram, over 31 of which is used for the system
file cache
wrote:
On Sat, Aug 29, 2009 at 5:20 AM, Luke Koops wrote:
Joseph S Wrote
If I have 14 drives in a RAID 10 to split between data tables
and indexes what would be the best way to allocate the drives
for performance?
RAID-5 can be much faster than RAID-10 for random reads and writes. It is much
s
Scott Marlowe wrote:
After that you have to start looking at hardware. Soimething as
simple as a different drive for indexes and another for WAL, and
another for the base tables can make a big difference.
If I have 14 drives in a RAID 10 to split between data tables and
indexes what would be
Greg Smith wrote:
The main two things you can do to improve this on the database side:
-Increase checkpoint_segments, which reduces how often updated data has
to be flushed to disk
It fsync is turned off, does this matter so much?
--
Sent via pgsql-performance mailing list (pgsql-perform
If I run " dd if=/dev/zero bs=1024k of=file count=1000 " iostat shows me:
Device:tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 671.5088.00113496.00176 226992
However postgres 8.3.7 doing a bulk data write (a slony slave, doing
inserts a
After upgrading to 8.2.3 INSERTs and UPDATEs on one of my tables became
incredibly slow. I traced the problem to one of my triggers that calls
one of my defined functions (that is IMMUTABLE). If I inline the
function instead of calling it the runtime for my test update drops from
10261.234 m
