[PERFORM] pg9 replication over WAN ?

2011-10-05 Thread Ben Ciceron
Hello, Has any performance or evaluation done for pg9.x streaming replication over WAN ? How adequate is the protocol to push WALs over long distance ? Any best practice tuning wal_* for WAN ? Cheers, Ben- -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make cha

Re: [PERFORM] Allow sorts to use more available memory

2011-10-05 Thread Bruce Momjian
Stephen Frost wrote: -- Start of PGP signed section. > * Robert Schnabel (schnab...@missouri.edu) wrote: > > And getting back to the to-do list entry and reading the related > > posts, it appears that even if you could set work_mem that high it > > would only use 2GB anyway. I guess that was the s

[PERFORM] Intel 710 Endurance Test Results

2011-10-05 Thread David Boreham
I ran a test using Intel's timed workload wear indication feature on a 100G 710 series SSD. The test works like this : you reset the wear indication counters, then start running some workload (in my case pgbench at scale 100 for 4 hours). During the test run a wear indication attribute can b

Re: [PERFORM] : Performance Improvement Strategy

2011-10-05 Thread Tom Lane
Scott Marlowe writes: > It used to be that cluster on a very randomly ordered table was much > slower than doing something like select * into newtable from oldtable > order by col1, col2; Is that still the case in 9.0/9.1? Fixed in 9.1, per release notes: * Allow CLUSTER to sort the tab

Re: [PERFORM] : Performance Improvement Strategy

2011-10-05 Thread Scott Marlowe
On Wed, Sep 21, 2011 at 11:57 AM, Greg Smith wrote: > On 09/21/2011 12:13 PM, Venkat Balaji wrote: >> >> I as a DBA, suggested to perform VACUUM FULL and RE-INDEXING + ANALYZE to >> ensure that IO performance and Indexing performance would be good > > > Read http://wiki.postgresql.org/wiki/VACUUM_

Re: [PERFORM] : Performance Improvement Strategy

2011-10-05 Thread Kevin Grittner
Raghavendra wrote: > Venkat Balaji wrote: >> [attempt to calculate file space from row layout and number of >> rows] > One more point to add to this good discussion, each row header > will occupy 24 bytes + 4 bytes pointer on page to tuple. Not to mention: http://www.postgresql.org/docs/9.

Re: [PERFORM] : Performance Improvement Strategy

2011-10-05 Thread Guillaume Cottenceau
Venkat Balaji writes: > Hello, > > I was attempting to calculate the actual occupied space by a Table. SELECT relname, reltuples, pg_size_pretty(relpages*8*1024) as size FROM pg_class, pg_namespace WHERE pg_namespace.oid = pg_class.relnamespace AND relkind = 'r' AND nspname = 'public' ORDER BY

Re: [PERFORM] : Performance Improvement Strategy

2011-10-05 Thread Raghavendra
On Wed, Oct 5, 2011 at 2:38 PM, Venkat Balaji wrote: > Hello, > > I was attempting to calculate the actual occupied space by a Table. > > Below is what i did - > > I summed up the avg_width of each column of a table from pg_stats, which > gives me the average size of a row (277 bytes). > > select*

Re: [PERFORM] : Performance Improvement Strategy

2011-10-05 Thread Venkat Balaji
Hello, I was attempting to calculate the actual occupied space by a Table. Below is what i did - I summed up the avg_width of each column of a table from pg_stats, which gives me the average size of a row (277 bytes). select* sum(avg_width) as average_row_size from pg_stats *where tablename='ta