Re: [PERFORM] General performance questions about postgres on Apple

2004-06-06 Thread Tom Lane
Sean Shanny [EMAIL PROTECTED] writes: We have the following setting for random page cost: random_page_cost = 1# units are one sequential page fetch cost Any suggestions on what to bump it up to? Well, the default setting is 4 ... what measurements prompted you to reduce it to 1?

Re: [PERFORM] General performance questions about postgres on Apple

2004-06-06 Thread Gregory S. Williamson
To: Sean Shanny Cc: [EMAIL PROTECTED] Subject:Re: [PERFORM] General performance questions about postgres on Apple In-reply-to: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Comments: In-reply-to Sean Shanny [EMAIL

Re: [PERFORM] General performance questions about postgres on Apple

2004-06-05 Thread scott.marlowe
On Fri, 20 Feb 2004, Sean Shanny wrote: max_connections = 100 # - Memory - shared_buffers = 16000 # min 16, at least max_connections*2, 8KB each sort_mem = 256000 # min 64, size in KB You might wanna drop sort_mem somewhat and just set it during your imports to

Re: [PERFORM] General performance questions about postgres on Apple

2004-02-23 Thread scott.marlowe
On Sun, 22 Feb 2004, Sean Shanny wrote: Tom, We have the following setting for random page cost: random_page_cost = 1# units are one sequential page fetch cost Any suggestions on what to bump it up to? We are waiting to hear back from Apple on the speed issues, so far we

Re: [PERFORM] General performance questions about postgres on Apple

2004-02-23 Thread Sean Shanny
Scott, We did try clustering on the date_key for the fact table below for a months worth of data as most of our requests for data are date range based, i.e. get me info for the time period between 2004-02-01 and 2004-02-07. This normally results in a plan that is doing an index scan on the

Re: [PERFORM] General performance questions about postgres on Apple

2004-02-23 Thread Josh Berkus
Scott, I am certainly open to any suggestions on how to deal with speed issues on these sorts of large tables, it isn't going to go away for us. :-( I'm not sure what to suggest. I can't think of anything off the top of my head that would improve cripplingly slow random seek times. This

Re: [PERFORM] General performance questions about postgres on Apple

2004-02-23 Thread Sean Shanny
Simon Riggs wrote: Sean Shanny Hardware: Apple G5 dual 2.0 with 8GB memory attached via dual fibre channel to a fully loaded 3.5TB XRaid. The XRaid is configured as two 7 disk hardware based RAID5 sets software striped to form a RAID50 set. The DB, WALS, etc are all on that file set.

Re: [PERFORM] General performance questions about postgres on Apple

2004-02-20 Thread Sean Shanny
scott.marlowe wrote: On Fri, 20 Feb 2004, Sean Shanny wrote: max_connections = 100 # - Memory - shared_buffers = 16000 # min 16, at least max_connections*2, 8KB each sort_mem = 256000 # min 64, size in KB You might wanna drop sort_mem somewhat and just set it