"Guillaume Smet" <guillaume.smet@gmail.com> writes:
> Tom, from my tests, the slow down goes down from 8% to 4% but it's
> still there and measurable. It's pretty consistent with the fact that
> you only saw a 3% slow down in your tests.
> The fact that you had only 3% overhead is still bugging me though.
> I'll dig a bit further to see if I can find something interesting or
> if there's something wrong with my setup.
Several of the major changes in 8.3 are I/O vs CPU tradeoffs which could be
causing a slowdown if you're measuring primarily CPU resources. I'm thinking
of both HOT and packed varlenas. I don't know if either of these are causing
your slowdown but it's possible.
HOT reduces the need to vacuum and reduces table and index bloat in exchange
for having to do some amount of vacuuming in the critical path. Effectively
it's moving some cpu work into the critical path which if you may not be
measuring in 8.2 if you weren't including vacuums in your measurements.
Packed varlenas reduces space usage -- especially for database which are
heavily based on text/varchar and "numeric" -- but at the expense of having to
expand those fields whenever they're operated on. For a RAM-resident test that
may be a net loss.
This is a conflict which will affect Postgres in the future as well. Generally
I/O costs win over cpu costs in databases since only relatively small systems
are cpu-bound. Large systems are typically I/O-bound.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services!
