> Are you sure? Have you tested the overall application to see if possibly
> you gain more on insert performance than you lose on select performanc?
Unfortunately dropping any of the indexes results in much worse select
performance that is not remotely clawed back by the improvement in
insert performance.
Actually there doesn't really seem to *be* that much improvement in
insert performance when going from 3 indexes to 2. I guess indexes must
be fairly cheap for PG to maintain?
> It's possible that compiling Postgres manually with proper optimizations
> could yield some improvements, as well as building a custom kernel in
> Redhat.
>
> Also, you don't mention which filesystem you're using:
> http://www.potentialtech.com/wmoran/postgresql.php
Yeah, I can imagine getting 5% extra from a slim kernel and
super-optimised PG.
The FS is ext3, metadata journaling (the default), mounted noatime.
> But if you're in the situation where you have more time than money,
> you may find that an overall audit of your app is worthwhile. Consider
> taking parts that are in perl (for example) and recoding them into C
> (that is, unless you've already identified that all the bottlenecks are
> at the PostgreSQL server)
I can pretty cheaply add more CPU horsepower for the app servers, as
they scale horizontally, so I can chuck in a couple (or 3, or 4, or ...)
more dual-cpu boxen with a gig of ram and tell the load balancer about
them. The problem with the DB is that that approach simply won't work -
the box just has to get bigger!
> I doubt if the suggestions I've made are going to get you 10x, but they
> may get you 2x, and then you only need the hardware to do 5x.
It all helps :-) A few percent here, a few percent there, pretty soon
you're talking serious improvements...
Thanks
Matt
