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 <>
> 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<>
> > 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
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to