Re: [HACKERS] Block level parallel vacuum WIP
От | Masahiko Sawada |
---|---|
Тема | Re: [HACKERS] Block level parallel vacuum WIP |
Дата | |
Msg-id | CAD21AoCV2dT1wTwsVykyg98=nh0J-NVMy6u+JbnZ8_jW0-fYbg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Block level parallel vacuum WIP (Claudio Freire <klaussfreire@gmail.com>) |
Список | pgsql-hackers |
On Sat, Jan 7, 2017 at 7:18 AM, Claudio Freire <klaussfreire@gmail.com> wrote: > On Fri, Jan 6, 2017 at 2:38 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote: >> table_size | indexes | parallel_degree | time >> ------------+---------+-----------------+---------- >> 6.5GB | 0 | 1 | 00:00:14 >> 6.5GB | 0 | 2 | 00:00:02 >> 6.5GB | 0 | 4 | 00:00:02 > > Those numbers look highly suspect. > > Are you sure you're not experiencing caching effects? (ie: maybe you > ran the second and third vacuums after the first, and didn't flush the > page cache, so the table was cached) > >> 6.5GB | 2 | 1 | 00:02:18 >> 6.5GB | 2 | 2 | 00:00:38 >> 6.5GB | 2 | 4 | 00:00:46 > ... >> 13GB | 0 | 1 | 00:03:52 >> 13GB | 0 | 2 | 00:00:49 >> 13GB | 0 | 4 | 00:00:50 > .. >> 13GB | 2 | 1 | 00:12:42 >> 13GB | 2 | 2 | 00:01:17 >> 13GB | 2 | 4 | 00:02:12 > > These would also be consistent with caching effects Since I ran vacuum after updated all pages on table, I thought that all data are in either shared buffer or OS cache. But anyway, I measured it at only one time so this result is not accurate. I'll test again and measure it at some times. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: