Re: [Patch] Optimize dropping of relation buffers using dlist

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: k(dot)jamison(at)fujitsu(dot)com, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)fujitsu(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [Patch] Optimize dropping of relation buffers using dlist
Date: 2020-10-05 05:52:45
Message-ID: CAA4eK1+2HyFJ6xh0_Hzt5UNqqeGE9eNTRzSA3GqOYG1a3mCOzA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 2, 2020 at 8:14 AM Kyotaro Horiguchi
<horikyota(dot)ntt(at)gmail(dot)com> wrote:
>
> At Thu, 1 Oct 2020 12:55:34 +0000, "k(dot)jamison(at)fujitsu(dot)com" <k(dot)jamison(at)fujitsu(dot)com> wrote in
> > On Thursday, October 1, 2020 4:52 PM, Tsunakawa-san wrote:
> >
>
> (I'm still mildly opposed to the function name, which seems exposing
> detail too much.)
>

Do you have any better proposal? BTW, I am still not sure whether it
is a good idea to expose a new API for this especially because we do
exactly the same thing in existing function smgrnblocks. Why not just
add a new bool *cached parameter in smgrnblocks which will be set if
we return cached value? I understand that we need to change the code
wherever we call smgrnblocks or maybe even extensions if they call
this function but it is not clear to me if that is a big deal. What do
you think? I am not opposed to introducing the new API but I feel that
adding a new parameter to the existing API to handle this case is a
better option.

--
With Regards,
Amit Kapila.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2020-10-05 06:29:51 Re: [Patch] Optimize dropping of relation buffers using dlist
Previous Message Dilip Kumar 2020-10-05 05:47:28 Re: [HACKERS] Custom compression methods