Re: a heavy duty operation on an "unused" table kills my server
От | Greg Smith |
---|---|
Тема | Re: a heavy duty operation on an "unused" table kills my server |
Дата | |
Msg-id | 4B5768CD.5030606@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: a heavy duty operation on an "unused" table kills my server (Matthew Wakeling <matthew@flymine.org>) |
Ответы |
Re: a heavy duty operation on an "unused" table kills my
server
|
Список | pgsql-performance |
Matthew Wakeling wrote: > On Fri, 15 Jan 2010, Greg Smith wrote: >> My theory has been that the "extra processing it has to perform" you >> describe just doesn't matter in the context of a fast system where >> physical I/O is always the bottleneck. > > Basically, to an extent, that's right. However, when you get 16 drives > or more into a system, then it starts being an issue. I guess if I test a system with *only* 16 drives in it one day, maybe I'll find out. Seriously though, there is some difference between a completely synthetic test like you noted issues with here, and anything you can see when running the database. I was commenting more on the state of things from the perspective of a database app, where I just haven't seen any of the CFQ issues I hear reports of in other contexts. I'm sure there are plenty of low-level tests where the differences between the schedulers is completely obvious and it doesn't look as good anymore, and I'll take a look at whether I can replicate the test case you saw a specific concern with here. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.com
В списке pgsql-performance по дате отправления: