Re: Bug: Buffer cache is not scan resistant
От | Luke Lonergan |
---|---|
Тема | Re: Bug: Buffer cache is not scan resistant |
Дата | |
Msg-id | C3E62232E3BCF24CBA20D72BFDCB6BF802CFC0C2@MI8NYCMAIL08.Mi8.com обсуждение исходный текст |
Ответ на | Re: Bug: Buffer cache is not scan resistant (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Hi Tom, > Now this may only prove that the disk subsystem on this > machine is too cheap to let the system show any CPU-related > issues. Try it with a warm IO cache. As I posted before, we see double the performance of a VACUUM from a table in IO cache when the shared buffer cache isn't being polluted. The speed with large buffer cache should be about 450 MB/s and the speed with a buffer cache smaller than L2 should be about 800 MB/s. The real issue here isn't the L2 behavior, though that's important when trying to reach very high IO speeds, the issue is that we're seeing the buffer cache pollution in the first place. When we instrument the blocks selected by the buffer page selection algorithm, we see that they iterate sequentially, filling the shared buffer cache. That's the source of the problem here. Do we have a regression test somewhere for this? - Luke
В списке pgsql-hackers по дате отправления: