Re: [PERFORM] best way to run maintenance script
"Vinubalaji Gopal" <[EMAIL PROTECTED]> writes: > On Fri, 2008-03-14 at 18:37 -0700, Tom Lane wrote: >> That's only a little bit better. Read about all the bug fixes you're > > Sure - will eventually upgrade it sometime - but it has to wait for > now :( Waiting for one of those bugs to bite you is a bad plan. We're not talking about an upgrade to 8.1, 8.2, or 8.3. We're talking about taking bug-fixes and security fixes for the release you're already using. Normally it's just a shutdown and immediate restart. There are exceptions listed in the 8.0.6 release notes which would require a REINDEX but they don't affect most people. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support! -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Benchmark: Dell/Perc 6, 8 disk RAID 10
I decided to reformat the raid 10 into ext2 to see if there was any real big difference in performance as some people have noted here is the test results please note the WAL files are still on the raid 0 set which is still in ext3 file system format. these test where run with the fsync as before. I made sure every thing was the same as with the first test. As you can see there is a 3 to 3.5 times increase in performance numbers just changing the file system With -S option set there is not change in performance numbers ---First Run 10 clients-- C:\Program Files\PostgreSQL\8.3\bin>pgbench -c 10 -t 4 -v -h 192.168.1.9 -U postgres play Password: starting vacuum...end. starting vacuum accounts...end. transaction type: TPC-B (sort of) scaling factor: 100 number of clients: 10 number of transactions per client: 4 number of transactions actually processed: 40/40 tps = 2108.036891 (including connections establishing) tps = 2112.902970 (excluding connections establishing) -Second Run 10 clients - C:\Program Files\PostgreSQL\8.3\bin>pgbench -c 10 -t 4 -v -h 192.168.1.9 -U postgres play Password: starting vacuum...end. starting vacuum accounts...end. transaction type: TPC-B (sort of) scaling factor: 100 number of clients: 10 number of transactions per client: 4 number of transactions actually processed: 40/40 tps = 2316.114949 (including connections establishing) tps = 2321.990410 (excluding connections establishing) -First Run 40 clients C:\Program Files\PostgreSQL\8.3\bin>pgbench -c 40 -t 1 -v -h 192.168.1.9 -U postgres play Password: starting vacuum...end. starting vacuum accounts...end. transaction type: TPC-B (sort of) scaling factor: 100 number of clients: 40 number of transactions per client: 1 number of transactions actually processed: 40/40 tps = 2675.585284 (including connections establishing) tps = 2706.707899 (excluding connections establishing) ---Second Run C:\Program Files\PostgreSQL\8.3\bin>pgbench -c 40 -t 1 -v -h 192.168.1.9 -U postgres play Password: starting vacuum...end. starting vacuum accounts...end. transaction type: TPC-B (sort of) scaling factor: 100 number of clients: 40 number of transactions per client: 1 number of transactions actually processed: 40/40 tps = 2600.560421 (including connections establishing) tps = 2629.952529 (excluding connections establishing) Select Only Option -- C:\Program Files\PostgreSQL\8.3\bin>pgbench -S -c 10 -t 4 -v -h 192.168.1.9 -U postgres play Password: starting vacuum...end. starting vacuum accounts...end. transaction type: SELECT only scaling factor: 100 number of clients: 10 number of transactions per client: 4 number of transactions actually processed: 40/40 tps = 18181.818182 (including connections establishing) tps = 18550.294486 (excluding connections establishing) C:\Program Files\PostgreSQL\8.3\bin>pgbench -S -c 40 -t 1 -v -h 192.168.1.9 -U postgres play Password: starting vacuum...end. starting vacuum accounts...end. transaction type: SELECT only scaling factor: 100 number of clients: 40 number of transactions per client: 1 number of transactions actually processed: 40/40 tps = 18991.548761 (including connections establishing) tps = 20729.684909 (excluding connections establishing) -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
[PERFORM] What is the best way to storage music files in Postgresql
I am going to embarkon building a music library using apache, postgresql and php. What is the best way to store the music files? Which file type should I use? -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] What is the best way to storage music files in Postgresql
Rich wrote: I am going to embarkon building a music library using apache, postgresql and php. What is the best way to store the music files? Which file type should I use? In Postgres, its all just binary data. It's entirely up to you which particular format you use. mp2, mp3 mp4, wmv, avi, whatever, it's all the same to Postgres. A better question is: Should you store the binary data in Postgres itself, or keep it in files and only store the filenames? The Postgres archives have several discussions of this topic, and the answer is, "it depends." Craig -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] What is the best way to storage music files in Postgresql
Rich wrote: I am going to embarkon building a music library using apache, postgresql and php. What is the best way to store the music files? Your options are either to use a BLOB within the database or to store paths to normal files in the file system in the database. I suspect using normal files will make backup and management a great deal easier than using in-database BLOBs, so personally I'd do it that way. Storing the audio files in the database does make it easier to keep the database and file system backups in sync, but I'm not really sure that's worth the costs. I'm sure that what you're doing has been done many times before, though, so even if you're not going to use one of the existing options you might at least want to have a look at how they work. Which file type should I use? I'm not sure I understand this question. Are you asking which audio compression codec and audio container file type (like "mp3", "aac", etc) you should use? If so, this is really not the right place to ask that. Do you mean which file /system/ ? -- Craig Ringer -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
