Author: Stephen Thompson <stephen AT seismo.berkeley DOT edu>
Date: Fri, 04 Jun 2010 10:58:04 -0700
Hello everyone, We recently attempted a mysql to postgresql migration for our bacula 5.0.2 server. The data migration itself was successful, however we are disappointly either getting the same or sig
Author: Stephen Thompson <stephen AT seismo.berkeley DOT edu>
Date: Fri, 04 Jun 2010 11:42:20 -0700
Correction: I didn't notice the 8k per unit settings at first with postgres 8.1. Should read: effective_cache_size = 786432 # 6Gb -- Stephen Thompson Berkeley Seismological Laboratory stephen AT seis
Assuming this is linux, you need to tweak /etc/sysctl/limits.conf a little: postgres soft memlock unlimited postgres hard memlock unlimited @postgres hard memlock unlimited @postgres soft memlock unl
Author: Stephen Thompson <stephen AT seismo.berkeley DOT edu>
Date: Fri, 04 Jun 2010 14:01:02 -0700
Thanks, yes it is Linux. I will look at those limits settings. And yes, I've built indexes and analyze (nothing to vacuum yet since it's a fresh import). Stephen -- Stephen Thompson Berkeley Seismolo
Which filesystem are you on too? I've found that ext3 is significantly faster than ext4 and xfs. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE P
Hello everyone, We recently attempted a mysql to postgresql migration for our bacula 5.0.2 server. The data migration itself was successful, however we are disappointly either getting the same or sig
Author: Stephen Thompson <stephen AT seismo.berkeley DOT edu>
Date: Mon, 07 Jun 2010 07:47:21 -0700
Yes, it's ext3. -- Stephen Thompson Berkeley Seismological Laboratory stephen AT seismo.berkeley DOT edu 215 McCone Hall # 4760 404.538.7077 (phone) University of California, Berkeley 510.643.5811 (f
Author: John Drescher <drescherjm AT gmail DOT com>
Date: Mon, 7 Jun 2010 11:00:36 -0400
That is only with certain workloads. ext3 is significantly slower than both at large file operations. Especially deletes where ext3 can take minutes to delete a 4GB file while the other two take les
Please don't top post, it makes threading harder to read. I'm using Ext4 - on a 48Gb machine with high performance raid controller (battery backup and 500Mb cache) with Raid10 Diskset. The database f
because that's what is supplied and supported by Redhat for their enterprise versions. Anything newer is unsupported by contracts but Redhat do backport newer bugfixes to older software builds while
Author: Florian Heigl <florian.heigl AT gmail DOT com>
Date: Mon, 7 Jun 2010 18:24:34 +0200
Hi all, Disclaimer: I don't know a dime's worth of databases per se. But I spend a lot of time hunting other peoples performance issues. :) I think you should start identifying the cause for this bit
Author: Florian Heigl <florian.heigl AT gmail DOT com>
Date: Mon, 7 Jun 2010 18:25:07 +0200
after all, you had to ask here, not at RedHat. -- 'Sie brauchen sich um Ihre Zukunft keine Gedanken zu machen' -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway
Author: Stephen Thompson <stephen AT seismo.berkeley DOT edu>
Date: Mon, 07 Jun 2010 09:28:16 -0700
Yes, Alan Brown answered this for me, but, yeah, it's a restriction based on our policy to use Centos (5.5.) packages which is at postgresql 8.1. It might be worth trying a compiled version of the la
Author: Stephen Thompson <stephen AT seismo.berkeley DOT edu>
Date: Mon, 07 Jun 2010 11:15:37 -0700
I totally agree. This was my first cause for concern when after the data import, I wanted to check that I still had the same number of rows. No, it does not swap, in this case or any other one I've t
Author: Martin Simmons <martin AT lispworks DOT com>
Date: Mon, 7 Jun 2010 20:10:42 +0100
Is counting all rows ever fast on postgres? For me, it runs a sequential scan, which is always slow. It is probably never done with millions of rows in a real application, so noone has optimized it.
Is your MySQL database in the MyISAM format ? If yes, then it's perfectly normal. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the luc
It runs a sequential scan because of MVCC. Please see http://wiki.postgresql.org/wiki/Slow_Counting I don't know MySQL very well, but I imagine that a count(*) on an InnoDB database should be as slow
Author: Stephen Thompson <stephen AT seismo.berkeley DOT edu>
Date: Mon, 07 Jun 2010 13:04:48 -0700
Yes. So it sounds like the row count is a red herring in saying there's a performance problem with postgres. I'll try to ignore that result then and concentrate on the queries like the one that produ
One the scale you're using it should be, however I have doubts about the amount of physical memory you have installed for the number of records being handled - if at all possible you should add more.