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 something else to the discussion: have you looked at
> memcached yet? Or pgpool? If you haven't, start there.
>
memcahced has been mentioned in some discussions, but I have not studied it yet.
--
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] 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 about the case where I will have almost 100% selects, but still needs something better than a plain key-value storage so I can do some sql queries. The server will just boot, load data, run, hopefully not crash but if it would, just start over with load and run. -- 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] 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 selects). But thanks for the suggestions on the more general parameters. "running with scissors" sounds nice :-) -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
[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 changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
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. Newer Arecas (the 1680 series) use an > ethernet port for traps and such, so no need for special software that > might be kernel version dependent. > > Both cost about the same for their top of the line cards. > > Make sure you have battery backed cache. While browsing the net I found a server with a raid controller HP Smart Array P400/512MB BBWC Controller How does one know what this is, if it is any good or so? I guess they just stuck their "HP" label onto some other raid controller? I could write HP but I guess that wouldn't help much. And I could also look through the archives for the mailinglist. When I find the time,I'll do so and try to create a wiki page. The problem with this kind of built-in hardware is that it might suck, and then you can't plug in any other hardware in the box. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
[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 about, but shouldn't geneeral advice be like: 1) A fast CPU but not on the bleeding edge 2) As much RAM as you can fit into the machine without paying way to much for it. Use the fastest ram you can find (what is it called today? PC 1333 MHz or something like that?) 3) Fast harddiscs. Best is raid X (what raid should one use?) 4) Use software raid unless you have the money to buy a raid controller, in which case here is the ranking of them ordered by quality and a general comment on exactly how much better they are than the one below on the list ;-) -- 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] Where do a novice do to make it run faster?
Here is some more information. Size of database: du -sh /var/lib/pgsql/data/base/* 4,1M/var/lib/pgsql/data/base/1 4,1M/var/lib/pgsql/data/base/10792 4,1M/var/lib/pgsql/data/base/10793 9,1M/var/lib/pgsql/data/base/16388 11M /var/lib/pgsql/data/base/19233 1,6G/var/lib/pgsql/data/base/20970 I'm not sure what the size acctually is... But I can't imagine that it is 1,6 GB!!! I'd say I have 11MB of data in it... Cpu is Intel CoreDuo E6750, 4 GB RAM Harddiscs are two Segate 320 GB SATA discs. running software raid (!!), raid-1.Yes, this might be a big 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 > sata discs (mirror raid) > > The queries are most select/inserts.. I guess... I'm not sure exactly > what to answer on that. > "explain analyze" is something I have not read about yet. > > > 2008/4/28 Claus Guttesen <[EMAIL PROTECTED]>: > > > > > 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 now, but in the future perhaps. > > > 2) will be quite hard right now since there is more code than time. > > > 3) almost like 2 but perhaps more do-able with the current constraints. > > > 4) This seems to be the easiest one to start with... > > > > > > So what should I do/read concerning point 4? > > > If you have other good suggestions I'd be very interested in that. > > > > > > Thank you :-) > > > > You can provide information postgresql-version, what type of queries > > you're running, some explain analyze of those, and what type of > > hardware you're running and what OS is installed. > > > > -- > > regards > > Claus > > > > When lenity and cruelty play for a kingdom, > > the gentlest gamester is the soonest winner. > > > > Shakespeare > > > -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
[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 now, but in the future perhaps. 2) will be quite hard right now since there is more code than time. 3) almost like 2 but perhaps more do-able with the current constraints. 4) This seems to be the easiest one to start with... So what should I do/read concerning point 4? If you have other good suggestions I'd be very interested in that. Thank you :-) -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
