Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem
От | Claudio Freire |
---|---|
Тема | Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem |
Дата | |
Msg-id | CAGTBQpY+TH27LKq93RSP=ZrQVWFMQZAOq8g_8qfwuc=9Fb0fCA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Список | pgsql-hackers |
On Wed, Feb 7, 2018 at 12:50 AM, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote: > Hello, > > At Tue, 6 Feb 2018 10:41:22 -0300, Claudio Freire <klaussfreire@gmail.com> wrote in <CAGTBQpaufC0o8OikWd8=5biXcbYjT51mPLfmy22NUjX6kUED0A@mail.gmail.com> >> On Tue, Feb 6, 2018 at 10:18 AM, Claudio Freire <klaussfreire@gmail.com> wrote: >> > On Tue, Feb 6, 2018 at 4:35 AM, Kyotaro HORIGUCHI >> > <horiguchi.kyotaro@lab.ntt.co.jp> wrote: >> >>> It's starting to look like a timing effect indeed. >> >> >> >> It seems to be truncation skip, maybe caused by concurrent >> >> autovacuum. >> > >> > Good point, I'll also disable autovacuum on vactst. >> > >> >> See lazy_truncate_heap() for details. Updates of >> >> pg_stat_*_tables can be delayed so looking it also can fail. Even >> >> though I haven't looked the patch closer, the "SELECT >> >> pg_relation_size()" doesn't seem to give something meaningful >> >> anyway. >> > >> > Maybe then "explain (analyze, buffers, costs off, timing off, summary >> > off) select * from vactst" then. > > Ah, sorry. I meant by the above that it gives unstable result > with autovacuum. So pg_relation_size() is usable after you turned > of autovacuum on the table. You did mention stats could be delayed >> > The point is to check that the relation's heap has 0 pages. >> >> Attached rebased patches with those changes mentioned above, namely: >> >> - vacuum test now creates vactst with autovacuum disabled for it >> - vacuum test on its own parallel group >> - use explain analyze instead of pg_relation_size to check the >> relation is properly truncated > > The problematic test was in the 0001..v14 patch. The new > 0001..v15 is identical to v14 and instead 0003-v8 has additional > part that edits the test and expects added by 0001 into the shape > as above. It seems that you merged the fixup onto the wrong > commit. > > And may we assume it correct that 0002 is missing in this > patchset? Sounds like I botched the rebase. Sorry about that. Attached are corrected versions (1-v16 and 3-v9)
Вложения
В списке pgsql-hackers по дате отправления: