Re: [PERFORM] RT3.4 query needed a lot more tuning with 9.2 than it did with 8.1
On Tue, 30 Apr 2013 06:20:55 -0500, Christoph Berg christoph.b...@credativ.de wrote: Hi, this is more of a report than a question, because we thought this would be interesting to share. We recently (finally) migrated an Request Tracker 3.4 database running on 8.1.19 to 9.2.4. The queries used by rt3.4 are sometimes weird, but 8.1 coped without too much tuning. The schema looks like this: What version of DBIx-SearchBuilder do you have on that server? The RT guys usually recommend you have the latest possible so RT is performing the most sane/optimized queries possible for your database. I honestly don't know if it will make a difference for you, but it's worth a shot. -- 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] Any experience using shake defragmenter?
On Sun, 30 Jan 2011 14:11:51 -0600, Mladen Gogala mladen.gog...@vmsinfo.com wrote: Did anyone try using shake while the cluster is active? Any problems with corruption or data loss? I ran the thing on my home directory and nothing was broken. I didn't develop any performance test, so cannot vouch for the effectiveness of the procedure. Did anyone play with that? Any positive or negative things to say about shake? Why do you feel the need to defrag your *nix box? Regards, Mark -- 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] Migrating to Postgresql and new hardware
On Tue, 18 Jan 2011 16:06:17 -0600, Strange, John W john.w.stra...@jpmchase.com wrote: Of course this is based on my experience, and I have my fireproof suit since I mentioned the word fusionIO :) I'll throw a fire blanket up as well. We have a customer who has been running Fusion IO with Postgres for about 2 years. They get amazing performance, but also aren't running fsync. They haven't had corruption with OS crashes (they're very abusive to their CentOS install), but did with a power outage (a UPS of ours went up in smoke; they weren't paying for N+1 power). Now their data is mostly static; they run analytics once a day and if they have a problem they can reload yesterday's data and run the analytics again to get back up to speed. If this is the type of stuff you're doing and you can easily get your data back to a sane state by all means give FusionIO a whirl! This customer did discuss this with me in length last time they stopped in and also pointed out that FusionIO was announced as being a major part of some trading company or bank firm's database performance junk. I don't know the details, but I think he said they were out of Chicago. If anyone knows what I'm talking about please share the link. Either way, it seems that people are actually doing money transactions on FusionIO, so you can either take that as comforting reassurance or you can start getting really nervous about the stock market :-) Regards, Mark PS, don't turn off fsync unless you know what you're doing. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
