On Thu, Sep 07, 2023 at 04:34:20PM +0530, Ashutosh Bapat wrote:
> I would still love to see some numbers. It's not that hard. Either
> using my micro benchmark or Michael's. We may or may not see an
> improvement. But at least we tried. But Michael feels otherwise,
> changing it to RoC is fine.
I
On Thu, Sep 7, 2023 at 3:05 PM Junwang Zhao wrote:
>
> On Thu, Sep 7, 2023 at 5:07 PM Ashutosh Bapat
> wrote:
> >
> > Forgot to attach the patch.
>
> LGTM
>
> Should I change the status to ready for committer now?
>
I would still love to see some numbers. It's not that hard. Either
using my
On Thu, Sep 7, 2023 at 5:07 PM Ashutosh Bapat
wrote:
>
> Forgot to attach the patch.
LGTM
Should I change the status to ready for committer now?
>
> On Thu, Sep 7, 2023 at 1:22 PM Ashutosh Bapat
> wrote:
> >
> > Hi Junwang,
> > We leave a line blank after variable declaration as in the
Forgot to attach the patch.
On Thu, Sep 7, 2023 at 1:22 PM Ashutosh Bapat
wrote:
>
> Hi Junwang,
> We leave a line blank after variable declaration as in the attached patch.
>
> Otherwise the patch looks good to me.
>
> The function modified by the patch is only used by extension
> pgrowlocks.
On Thu, Sep 7, 2023 at 4:04 PM Michael Paquier wrote:
>
> On Thu, Sep 07, 2023 at 01:22:07PM +0530, Ashutosh Bapat wrote:
> > Otherwise the patch looks good to me.
> >
> > The function modified by the patch is only used by extension
> > pgrowlocks. Given that the function will be invoked as many
On Thu, Sep 07, 2023 at 01:22:07PM +0530, Ashutosh Bapat wrote:
> Otherwise the patch looks good to me.
>
> The function modified by the patch is only used by extension
> pgrowlocks. Given that the function will be invoked as many times as
> the number of locked rows in the relation, the patch
Hi Junwang,
We leave a line blank after variable declaration as in the attached patch.
Otherwise the patch looks good to me.
The function modified by the patch is only used by extension
pgrowlocks. Given that the function will be invoked as many times as
the number of locked rows in the
On Thu, Aug 10, 2023 at 4:11 PM Ashutosh Bapat
wrote:
>
> Please add this to commitfest so that it's not forgotten.
>
Added [1], thanks
[1]: https://commitfest.postgresql.org/44/4495/
> On Wed, Aug 9, 2023 at 8:37 PM Junwang Zhao wrote:
> >
> > On Wed, Aug 9, 2023 at 10:46 PM Ashutosh Bapat
>
Please add this to commitfest so that it's not forgotten.
On Wed, Aug 9, 2023 at 8:37 PM Junwang Zhao wrote:
>
> On Wed, Aug 9, 2023 at 10:46 PM Ashutosh Bapat
> wrote:
> >
> > On Wed, Aug 9, 2023 at 9:30 AM Junwang Zhao wrote:
> > >
> > > In function `BackendXidGetPid`, when looping every
On Wed, Aug 9, 2023 at 10:46 PM Ashutosh Bapat
wrote:
>
> On Wed, Aug 9, 2023 at 9:30 AM Junwang Zhao wrote:
> >
> > In function `BackendXidGetPid`, when looping every proc's
> > TransactionId, there is no need to access its PGPROC since there
> > is shared memory access:
On Wed, Aug 9, 2023 at 9:30 AM Junwang Zhao wrote:
>
> In function `BackendXidGetPid`, when looping every proc's
> TransactionId, there is no need to access its PGPROC since there
> is shared memory access: `arrayP->pgprocnos[index]`.
>
> Though the compiler can optimize this kind of
In function `BackendXidGetPid`, when looping every proc's
TransactionId, there is no need to access its PGPROC since there
is shared memory access: `arrayP->pgprocnos[index]`.
Though the compiler can optimize this kind of inefficiency, I
believe we should ship with better code.
12 matches
Mail list logo
