Re: [PERFORM] Running PostgreSQL as fast as possible no matter the consequences

>> If you just wanted PostgreSQL to go as fast as possible WITHOUT any >> care for your data (you accept 100% dataloss and datacorruption if any >> error should occur), what settings should you use then? > > Others have suggested appropriate parameters ("running with scissors"). > > I'd like to add

Re: [PERFORM] Running PostgreSQL as fast as possible no matter the consequences

>> If you just wanted PostgreSQL to go as fast as possible WITHOUT any >> care for your data (you accept 100% dataloss and datacorruption if any >> error should occur), what settings should you use then? >> > > > I'm just curious, what do you need that for? > > regards > Szymon I was just thinking

Re: [PERFORM] Running PostgreSQL as fast as possible no matter the consequences

> Turn off fsync and full_page_writes (i.e. running with scissors). > Also depends on what you mean by "as fast as possible".  Fast at doing > what?  Bulk inserts, selecting from massive tables? I guess some tuning has to be done to make it work well with the particular workload (in this case most

[PERFORM] Running PostgreSQL as fast as possible no matter the consequences

Hi there. If you just wanted PostgreSQL to go as fast as possible WITHOUT any care for your data (you accept 100% dataloss and datacorruption if any error should occur), what settings should you use then? -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make chang

Re: [PERFORM] [PERFORMANCE] Buying hardware

>> 4) Use software raid unless you have the money to buy a raid >> controller, in which case here is the ranking of them >> > > Areca and 3ware/Escalade are the two best controllers for the money > out right now. They tend to take turns being the absolute best as > they release new cards. N

[PERFORM] [PERFORMANCE] Buying hardware

So, the eternal problem with what hardware to buy. I really miss a hardware buying guide for database servers now that I'm about to buy one.. Some general guidelines mixed with ranked lists of what hardware that is best, shouldn't that be on the wiki?. THis is of course very difficult to advice a

Re: [PERFORM] Where do a novice do to make it run faster?

performance hit, but that is what I have right now, in the future I can throw more money on hardware. Will I see a general improvement in performance in 8.3.X over 8.1.11? 2008/4/29 A B <[EMAIL PROTECTED]>: > Right now, version 8.1.11 on centos.x86-64, intel dual core cpu with 2 >

[PERFORM] Where do a novice do to make it run faster?

So, it is time to improve performance, it is running to slow. AFAIK (as a novice) there are a few general areas: 1) hardware 2) rewriting my queries and table structures 3) using more predefined queries 4) tweek parameters in the db conf files Of these points: 1) is nothing I can do about right n