"Guillaume Smet" <[EMAIL PROTECTED]> 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! ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
