Re: 8.3devel slower than 8.2 under read-only load
От | Gregory Stark |
---|---|
Тема | Re: 8.3devel slower than 8.2 under read-only load |
Дата | |
Msg-id | 87ir3rippg.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: 8.3devel slower than 8.2 under read-only load ("Guillaume Smet" <guillaume.smet@gmail.com>) |
Ответы |
Re: 8.3devel slower than 8.2 under read-only load
Re: 8.3devel slower than 8.2 under read-only load Re: 8.3devel slower than 8.2 under read-only load |
Список | pgsql-hackers |
"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!
В списке pgsql-hackers по дате отправления: