[PERFORM] Avoiding vacuum full on an UPDATE-heavy table

2004-05-21 Thread Bill Montgomery
. CPU 0.38s/0.32u sec elapsed 1.33 sec. INFO: Pages 13295: Changed 276, Empty 0; Tup 34540: Vac 77066, Keep 0, UnUsed 474020. Total CPU 3.34s/1.29u sec elapsed 125.00 sec. INFO: Analyzing public.xxx Best Regards, Bill Montgomery ---(end of broadcast

Re: [PERFORM] Avoiding vacuum full on an UPDATE-heavy table

2004-05-21 Thread Bill Montgomery
help :-( Best Regards, Bill Montgomery ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

Re: [PERFORM] [GENERAL] performance very slow

2004-05-26 Thread Bill Montgomery
write operations require more frequent vacuuming. Good luck. Best Regards, Bill Montgomery The postresql.conf say: #--- # RESOURCE USAGE (except WAL

Re: [PERFORM] High load average with PostgreSQL 7.4.2 on debian/ibm

2004-06-29 Thread Bill Montgomery
; if your budget for disks is limited, RAID 5 is the next best thing. Also, you will get more bang for your buck with a larger number of 10k disks than a smaller number of 15k disks. Good luck, Bill Montgomery ---(end of broadcast)--- TIP 3: if posting

Re: [PERFORM] Help specifying new machine

2004-08-09 Thread Bill Montgomery
to let the smarter filesystem cache handle the bulk of your caching needs. Comments and advice gratefully received. Rory Best Luck, Bill Montgomery ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your

Re: [PERFORM] Slow select, insert, update

2004-08-10 Thread Bill Montgomery
pg_autovacuum. Good Luck, Bill Montgomery ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html

Re: [PERFORM] Column order performance

2004-08-10 Thread Bill Montgomery
Josh Berkus wrote: Does the order of columns of varying size have any effect on SELECT/INSERT/UPDATE/and/or/DELETE performance? Take the example where an integer primary key is listed first in the table and alternatively listed after some large varchar or text columns? No, the order of the

Re: [PERFORM] Excessive context switching on SMP Xeons

2004-10-05 Thread Bill Montgomery
? If so, is the expense of a 64-bit system worth it, or is the price/performance for PostgreSQL still better on an alternative 32-bit platform, like AthlonMP? Best Regards, Bill Montgomery ---(end of broadcast)--- TIP 3: if posting/reading through Usenet

Re: [PERFORM] Excessive context switching on SMP Xeons

2004-10-06 Thread Bill Montgomery
in there for my setup? Thanks, Bill Montgomery ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

Re: [PERFORM] Excessive context switching on SMP Xeons

2004-10-07 Thread Bill Montgomery
Alan Stange wrote: Here's a few numbers from the Opteron 250. If I get some time I'll post a more comprehensive comparison including some other systems. The system is a Sun v20z. Dual Opteron 250, 2.4Ghz, Linux 2.6, 8 GB memory. I did a compile and install of pg 8.0 beta 3. I created a

Re: [PERFORM] Excessive context switching on SMP Xeons

2004-10-07 Thread Bill Montgomery
Michael Adler wrote: On Thu, Oct 07, 2004 at 11:48:41AM -0400, Bill Montgomery wrote: Alan Stange wrote: The same test on a Dell PowerEdge 1750, Dual Xeon 3.2 GHz, 512k cache, HT on, Linux 2.4.21-20.ELsmp (RHEL 3), 4GB memory, pg 7.4.5: Far less performance that the Dual Opterons with a low