You can check Your efficient of memcached caching. This could be
critical. Read about getting statistic from memcached:
this is the fastest element of ReviewBoard.
If You still belive this is database engine bottle neck here is good
article witch talk about Postgres tuning also:
On Jun 10, 8:56 pm, Stephen Gallagher <step...@gallagherhome.com>
> Well, right now 4-8s for a page refresh is just barely within the
> tolerable limits of my users. I'm trying to determine whether it makes
> more sense to migrate to MySQL (if it would be better performance)
> I was also curious whether ReviewBoard's reference implementation was
> running on postgresql and whether there were any tuning tricks I should
> be aware of.
> On 06/10/2010 02:53 PM, Jan Koprowski wrote:
> > It is probably between SQLite and PostgreSQL. But this is delay is
> > proportional to scalable. SQLite is not scalable at all, PostgreSQL is
> > most scalable free SQL database.
> > On Jun 9, 9:39 pm, Stephen Gallagher<step...@gallagherhome.com>
> > wrote:
> >> I'm curious, what database is thehttp://reviews.reviewboard.orgserver
> >> using? We deployed on PostgreSQL recently, and I've noticed a distinct
> >> performance issue with it.
> >> I can only directly compare it to SQLite, but of course that's local
> >> access. But we went from< 1s responses on webpages to 4-8s per page
> >> when backed by Postgresql (on a private network with very little traffic).
> >> How is the performance when backed by MySQL?
Want to help the Review Board project? Donate today at
Happy user? Let us know at http://www.reviewboard.org/users/
To unsubscribe from this group, send email to
For more options, visit this group at