Re: [PERFORM] Running 9 in production? Sticking with 8.4.4 for a while?
Tory, We will continue to test under 9.0 but will keep production at 8.4.4 for a while longer as we want to see what kinds of issues show up over the next few weeks with 9.0. 9.0 has some features we would like to use but it isn't worth the risk of production. I think that the PostGres team has one of the best develop and test cycle management systems but there is always things that are going to pop up after a release. It just depends on the level of pain your willing to suffer. It seems that the developers are able to track down and kill bugs in a timely manner so I would expect to see a 9.0.1 version in the near future. At that point we'll start doing a lot more tire kicking. Best Regards Mike Gould Tory M Blue tmb...@gmail.com wrote: I'm doing an OS upgrade and have been sitting on 8.4.3 for sometime. I was wondering if it's better for the short term just to bring things to 8.4.4 and let 9.0 bake a bit longer, or are people with large data sets running 9.0 in production already? Just looking for 9.0 feedback (understand it's still quite new). Thanks Tory -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance -- Michael Gould, Managing Partner Intermodal Software Solutions, LLC 904.226.0978 904.592.5250 fax -- 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 tuning for postgres
In my opinion it depends on the application, the priority of the application and whether or not it is a commercially sold product, but depending on your needs you might want to consider having a 3rd party vendor who has expertise in this process review and help tune the application. One vendor that I know does this is EnterpriseDB. I've worked with other SQL engines and have a lot of experience tuning queries in a couple of the environments but PostGresql isn't one of them. Having an experienced DBA review your system can make the difference between night and day. Best Regards Michael Gould Kevin Grittner kevin.gritt...@wicourts.gov wrote: Yogesh Naik yogesh_n...@persistent.co.in wrote: I am performing a DB insertion and update for 3000+ records and while doing so i get CPU utilization to 100% with 67% of CPU used by postgres I have also done optimization on queries too... Is there any way to optimized the CPU utilization for postgres We'd need a lot more information before we could make useful suggestions. Knowing something about your hardware, OS, exact PostgreSQL version, postgresql.conf contents, the table definition, any foreign keys or other constraints, and exactly how you're doing the inserts would all be useful. Please read this and repost: http://wiki.postgresql.org/wiki/SlowQueryQuestions -Kevin -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance -- Michael Gould, Managing Partner Intermodal Software Solutions, LLC 904.226.0978 904.592.5250 fax -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
[PERFORM] position in DDL of columns used in indexes
In other SQL engines that I've used, it is recommended that the columns that are used in various indexes be placed at the beginning of a row since at some point (depending on the engine and/or pagesize) wide rows could end up on other pages. From a performance standpoint on large tables this makes a big difference. Is the same true with Postgres. Should I try and make sure that my indexes fit in the first 8192 bytes? Bes Regards -- Michael Gould, Managing Partner Intermodal Software Solutions, LLC 904.226.0978 904.592.5250 fax
