ould be awesome.
Thank you
Ogden
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
eavy calculation queries. Writing on the
RAID 5 really made things crawl. For lots of writing, I think RAID 10 is the
best. It should also be noted that I changed my filesystem from ext3 to XFS -
this is something you can look into as well.
Ogden
On Aug 17, 2011, at 4:17 PM, Greg Smith wrote:
> On 08/17/2011 02:26 PM, Ogden wrote:
>> I am using bonnie++ to benchmark our current Postgres system (on RAID 5)
>> with the new one we have, which I have configured with RAID 10. The drives
>> are the same (SAS 15K). I trie
On Aug 18, 2011, at 2:07 AM, Mark Kirkwood wrote:
> On 18/08/11 17:35, Craig Ringer wrote:
>> On 18/08/2011 11:48 AM, Ogden wrote:
>>> Isn't this very dangerous? I have the Dell PERC H700 card - I see that it
>>> has 512Mb Cache. Is this the same th
On Aug 17, 2011, at 4:16 PM, Greg Smith wrote:
> On 08/17/2011 02:26 PM, Ogden wrote:
>> I am using bonnie++ to benchmark our current Postgres system (on RAID 5)
>> with the new one we have, which I have configured with RAID 10. The drives
>> are the same (SAS 15K). I trie
On Aug 17, 2011, at 3:56 PM, k...@rice.edu wrote:
> On Wed, Aug 17, 2011 at 03:40:03PM -0500, Ogden wrote:
>>
>> On Aug 17, 2011, at 1:35 PM, k...@rice.edu wrote:
>>
>>> On Wed, Aug 17, 2011 at 01:32:41PM -0500, Ogden wrote:
>>>>
>>>
On Aug 17, 2011, at 1:35 PM, k...@rice.edu wrote:
> On Wed, Aug 17, 2011 at 01:32:41PM -0500, Ogden wrote:
>>
>> On Aug 17, 2011, at 1:31 PM, k...@rice.edu wrote:
>>
>>> On Wed, Aug 17, 2011 at 01:26:56PM -0500, Ogden wrote:
>>>> I am using bonnie++ to
On Aug 17, 2011, at 2:14 PM, Scott Marlowe wrote:
> On Wed, Aug 17, 2011 at 12:56 PM, Tomas Vondra wrote:
>>
>> I think you've mentioned the database is on 6 drives, while the other
>> volume is on 2 drives, right? That makes the OS drive about 3x slower
>> (just a rough estimate). But if the d
On Aug 17, 2011, at 1:56 PM, Tomas Vondra wrote:
> On 17 Srpen 2011, 18:39, Ogden wrote:
>>> Yes, but it greatly depends on the amount of WAL and your workload. If
>>> you
>>> need to write a lot of WAL data (e.g. during bulk loading), this may
>>> signifi
On Aug 17, 2011, at 1:33 PM, Gary Doades wrote:
> On 17/08/2011 7:26 PM, Ogden wrote:
>> I am using bonnie++ to benchmark our current Postgres system (on RAID 5)
>> with the new one we have, which I have configured with RAID 10. The drives
>> are the same (SAS 15K). I trie
On Aug 17, 2011, at 1:48 PM, Andy Colson wrote:
> On 8/17/2011 1:35 PM, k...@rice.edu wrote:
>> On Wed, Aug 17, 2011 at 01:32:41PM -0500, Ogden wrote:
>>>
>>> On Aug 17, 2011, at 1:31 PM, k...@rice.edu wrote:
>>>
>>>> On Wed, Aug 17, 2011 at
On Aug 17, 2011, at 1:31 PM, k...@rice.edu wrote:
> On Wed, Aug 17, 2011 at 01:26:56PM -0500, Ogden wrote:
>> I am using bonnie++ to benchmark our current Postgres system (on RAID 5)
>> with the new one we have, which I have configured with RAID 10. The drives
>> are
am I reading
things wrong?
The benchmark results are here:
http://malekkoheavyindustry.com/benchmark.html
Thank you
Ogden
On Aug 17, 2011, at 9:44 AM, Tomas Vondra wrote:
> On 17 Srpen 2011, 3:35, Ogden wrote:
>> Hope all is well. I have received tremendous help from this list prior and
>> therefore wanted some more advice.
>>
>> I bought some new servers and instead of RAID 5 (which
On Aug 17, 2011, at 8:41 AM, Andy Colson wrote:
> On 8/16/2011 8:35 PM, Ogden wrote:
>> Hope all is well. I have received tremendous help from this list prior and
>> therefore wanted some more advice.
>>
>> I bought some new servers and instead of RAID 5 (which I thi
with before and made reporting queries blaze by
seq_page_cost = 1.0
random_page_cost = 3.0
cpu_tuple_cost = 0.5
effective_cache_size = 8192MB
Any help and input is greatly appreciated.
Thank you
Ogden
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to
On Apr 12, 2011, at 5:36 PM, Tomas Vondra wrote:
> Dne 12.4.2011 23:19, Ogden napsal(a):
>>
>> On Apr 12, 2011, at 4:09 PM, Tomas Vondra wrote:
>>
>>> Dne 12.4.2011 20:28, Ogden napsal(a):
>>>>
>>>> On Apr 12, 2011, at 1:16 PM, Tomas Vondr
On Apr 12, 2011, at 4:09 PM, Tomas Vondra wrote:
> Dne 12.4.2011 20:28, Ogden napsal(a):
>>
>> On Apr 12, 2011, at 1:16 PM, Tomas Vondra wrote:
>>
>>> Dne 12.4.2011 19:23, Ogden napsal(a):
>>>>
>>>> On Apr 12, 2011, at 12:18
On Apr 12, 2011, at 1:16 PM, Tomas Vondra wrote:
> Dne 12.4.2011 19:23, Ogden napsal(a):
>>
>> On Apr 12, 2011, at 12:18 PM, Andreas Kretschmer wrote:
>>
>>> Ogden wrote:
>>>
>>>> I have been wrestling with the configuration of the dedi
On Apr 12, 2011, at 12:18 PM, Andreas Kretschmer wrote:
> Ogden wrote:
>
>> I have been wrestling with the configuration of the dedicated Postges 9.0.3
>> server at work and granted, there's more activity on the production server,
>> but
>> the same querie
em = 512MB
seq_page_cost = 0.02# measured on an arbitrary scale
random_page_cost = 0.03
cpu_tuple_cost = 0.02
effective_cache_size = 8192MB
The planner costs seem a bit low but this was from suggestions from this very
list a while ago.
Thank you
Ogden
On Sep 21, 2010, at 6:30 PM, Tom Lane wrote:
> Ogden writes:
>> SELECT tr.id, tr.sid
>>FROM
>>test_registration tr,
>>INNER JOIN test_registration_result r on (tr.id =
>> r.test_reg
On Sep 21, 2010, at 2:34 PM, Ogden wrote:
>
> On Sep 21, 2010, at 2:16 PM, Greg Smith wrote:
>
>> Joshua D. Drake wrote:
>>> PostgreSQL's defaults are based on extremely small and some would say
>>> (non production) size databases. As a matter of
fine - I'll keep an
eye on things over the next few days.
I truly appreciate everyone's help.
Ogden
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
How odd, I set the following:
seq_page_cost = 1.0
random_page_cost = 2.0
And now the query runs in milliseconds as opposed to 14 seconds. Could this
really be the change? I am running ANALYZE now - how often is it recommended to
do this?
Thank you
Ogden
On Sep 21, 2010, at 1:51 PM
I assume you mean random_page_cost? It is currently set to 4.0 - is it better
to increase or decrease this value?
Thank you
Ogden
On Sep 21, 2010, at 1:06 PM, Kenneth Marshall wrote:
> You DB is more than likely cached. You should adjust your
> page costs to better reflect reality an
000MB
default_statistics_target = 200
free -m:
total used free sharedbuffers cached
Mem: 8003 7849153 0 25 7555
-/+ buffers/cache:268 7735
Swap: 7640 0 7639
Any help would be appreciated. Thank you very much.
Ogden
27 matches
Mail list logo
