Re: [Patch] Optimize dropping of relation buffers using dlist
От | Amit Kapila |
---|---|
Тема | Re: [Patch] Optimize dropping of relation buffers using dlist |
Дата | |
Msg-id | CAA4eK1KWB1R=cENyGaAZtNu7tEVdfXg9G77N2M=KB-f5NzUj0w@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: [Patch] Optimize dropping of relation buffers using dlist ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>) |
Ответы |
RE: [Patch] Optimize dropping of relation buffers using dlist
|
Список | pgsql-hackers |
On Wed, Sep 23, 2020 at 8:04 AM tsunakawa.takay@fujitsu.com <tsunakawa.takay@fujitsu.com> wrote: > > From: Amit Kapila <amit.kapila16@gmail.com> > > > > > Don't > > > > > we need to guarantee the cache to be valid while recovery? > > > > > > > > > > > > > One possibility could be that we somehow detect that the value we > > > > are using is cached one and if so then only do this optimization. > > > > > > I basically like this direction. But I'm not sure the additional > > > parameter for smgrnblocks is acceptable. > > > > > > But on the contrary, it might be a better design that > > > DropRelFileNodeBuffers gives up the optimization when > > > smgrnblocks(,,must_accurate = true) returns InvalidBlockNumber. > > > > > > > I haven't thought about what is the best way to achieve this. Let us see if > > Tsunakawa-San or Kirk-San has other ideas on this? > > I see no need for smgrnblocks() to add an argument as it returns the correct cached or measured value. > The idea is that we can't use this optimization if the value is not cached because we can't rely on lseek behavior. See all the discussion between Horiguchi-San and me in the thread above. So, how would you ensure that if we don't use Kirk-San's proposal? -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: