On Tue, Dec 6, 2022 at 12:00 AM Andres Freund wrote:
>
> Hi
Thanks for reviewing.
> FWIW, I don't see an advantage in 0003. If it allows us to make something else
> simpler / faster, cool, but on its own it doesn't seem worthwhile.
I've discarded this change.
> On 2022-12-02 16:31:58 -0800,
Hi,
On 2022-12-08 12:29:54 +0530, Bharath Rupireddy wrote:
> On Tue, Dec 6, 2022 at 12:00 AM Andres Freund wrote:
> > I think it'd be safe to optimize LWLockConflictsWithVar(), due to some
> > pre-existing, quite crufty, code. LWLockConflictsWithVar() says:
> >
> > * Test first to see
On Tue, Dec 6, 2022 at 12:00 AM Andres Freund wrote:
>
> FWIW, I don't see an advantage in 0003. If it allows us to make something else
> simpler / faster, cool, but on its own it doesn't seem worthwhile.
Thanks. I will discard it.
> I think it'd be safe to optimize LWLockConflictsWithVar(),
Hi,
FWIW, I don't see an advantage in 0003. If it allows us to make something else
simpler / faster, cool, but on its own it doesn't seem worthwhile.
On 2022-12-02 16:31:58 -0800, Nathan Bossart wrote:
> On Fri, Dec 02, 2022 at 04:32:38PM +0530, Bharath Rupireddy wrote:
> > On Fri, Dec 2,
On Fri, Dec 02, 2022 at 04:32:38PM +0530, Bharath Rupireddy wrote:
> On Fri, Dec 2, 2022 at 6:10 AM Andres Freund wrote:
>> I'm not sure this is quite right - don't we need a memory barrier. But I
>> don't
>> see a reason to not just leave this code as-is. I think this should be
>> optimized
On Fri, Dec 2, 2022 at 6:10 AM Andres Freund wrote:
>
> On 2022-11-25 16:54:19 +0530, Bharath Rupireddy wrote:
> > On Fri, Nov 25, 2022 at 12:16 AM Andres Freund wrote:
> > > I think we could improve this code more significantly by avoiding the
> > > call to
> > > LWLockWaitForVar() for all