Re: [Patch] Optimize dropping of relation buffers using dlist
От | Amit Kapila |
---|---|
Тема | Re: [Patch] Optimize dropping of relation buffers using dlist |
Дата | |
Msg-id | CAA4eK1JjPbyUuGLF=zXZNhBrf+FWcwiED1eEPKTJ2k+=Y5FrVw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [Patch] Optimize dropping of relation buffers using dlist (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
RE: [Patch] Optimize dropping of relation buffers using dlist
|
Список | pgsql-hackers |
On Thu, Dec 10, 2020 at 7:11 AM Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote: > > At Wed, 9 Dec 2020 16:27:30 +0530, Amit Kapila <amit.kapila16@gmail.com> wrote in > > On Wed, Dec 9, 2020 at 6:32 AM Kyotaro Horiguchi > > > Mmm. At least btree doesn't need to call smgrnblocks except at > > > expansion, so we cannot get to the optimized path in major cases of > > > truncation involving btree (and/or maybe other indexes). > > > > > > > AFAICS, btree insert should call smgrnblocks via > > btree_xlog_insert->XLogReadBufferForRedo->XLogReadBufferForRedoExtended->XLogReadBufferExtended->smgrnblocks. > > Similarly delete should also call smgrnblocks. Can you be bit more > > specific related to the btree case you have in mind? > > Oh, sorry. I wrongly looked to non-recovery path. smgrnblocks is > called during buffer loading while recovery. So, smgrnblock is called > for indexes if any update happens on the heap relation. > Okay, so this means that we can get the benefit of optimization in many cases in the Truncate code path as well even if we use 'cached' flag? If so, then I would prefer to keep the code consistent for both vacuum and truncate recovery code path. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: