> On 9 Nov 2021, at 15:28, Daniel Gustafsson wrote:
>
> This patch now fails to apply, probably due to a mostly trivial collision with
> fdd88571454e2b00dbe446e8609c6e4294ca89ae in the test files. Can you submit a
> rebased version?
I've marked this Returned with Feedback, please feel free to r
This patch now fails to apply, probably due to a mostly trivial collision with
fdd88571454e2b00dbe446e8609c6e4294ca89ae in the test files. Can you submit a
rebased version?
--
Daniel Gustafsson https://vmware.com/
On Mon, Jun 14, 2021 at 2:29 PM David Rowley wrote:
> Have you also thought about deferrable unique / primary key constraints?
>
> It's possible to the uniqueness temporarily violated during a
> transaction when the unique constraint is deferred,
Oh, yeah, very good question. I think many scenar
On Mon, 14 Jun 2021 at 10:03, Thomas Munro wrote:
>
> On Mon, Jun 14, 2021 at 12:54 AM David Rowley wrote:
> > I think a more optimal and nicer way of doing that would be setting
> > bits in a Bitmapset then checking bms_num_members is equal to
> > n_scan_keys.
>
> Shouldn't it be compared with i
On Mon, Jun 14, 2021 at 12:54 AM David Rowley wrote:
> I think a more optimal and nicer way of doing that would be setting
> bits in a Bitmapset then checking bms_num_members is equal to
> n_scan_keys.
Shouldn't it be compared with indnkeyatts? Yes, much nicer, thanks!
From 2325ae403196f73865f7c
On Mon, 14 Jun 2021 at 00:02, Thomas Munro wrote:
> Here's a highly experimental patch I came up with that seems to
> produce the right results in simple cases, without (yet) involving the
> planner.
+ /* Find all equality quals. */
+ for (int i = 0; i < n_scan_keys; ++i)
+ {
+ if (scan_keys[i].s
On Sat, Jun 12, 2021 at 2:35 PM Thomas Munro wrote:
> ... and here is the corresponding code change, with a test to
> demonstrate the change.
>
> I'm working on a proof-of-concept to skip the btree page lock
> sometimes too, which seems promising, but it requires some planner
> work which has temp
On Fri, Jun 28, 2019 at 12:55 PM Ashwin Agrawal wrote:
> On Thu, Jun 27, 2019 at 4:33 PM Thomas Munro wrote:
>>
>> Here's a patch I'd like to commit to fix the comment. We could look
>> at improving the actual code after
>> https://commitfest.postgresql.org/23/2169/ is done.
>
> Change looks goo
On Fri, Jun 28, 2019 at 12:55 PM Ashwin Agrawal wrote:
> On Thu, Jun 27, 2019 at 4:33 PM Thomas Munro wrote:
>> I wonder if it might be possible to avoid page locks on both the heap
>> *and* index in some limited cases, as I mentioned over here (just an
>> idea, could be way off base):
>>
>> http
On Fri, Jun 28, 2019 at 12:55 PM Ashwin Agrawal wrote:
> Change looks good to me.
Pushed, thanks.
--
Thomas Munro
https://enterprisedb.com
On Thu, Jun 27, 2019 at 4:33 PM Thomas Munro wrote:
> Here's a patch I'd like to commit to fix the comment. We could look
> at improving the actual code after
> https://commitfest.postgresql.org/23/2169/ is done.
>
Change looks good to me.
> I wonder if it might be possible to avoid page lock
On Fri, Feb 8, 2019 at 4:58 AM Thomas Munro
wrote:
> On Thu, May 17, 2018 at 3:49 AM Heikki Linnakangas wrote:
> > On 14/05/18 02:15, Thomas Munro wrote:
> > > The first sentence of that comment is no longer true as of commit
> > > c01262a8 (2013). As for whether it's necessary to predicate-lock
On Thu, May 17, 2018 at 3:49 AM Heikki Linnakangas wrote:
> On 14/05/18 02:15, Thomas Munro wrote:
> > Since commit cdf91edb (2012), nodeIndexonlyscan.c says:
> >
> > /*
> > * Predicate locks for index-only scans must be
> > acquired at the page
> >
On 14/05/18 02:15, Thomas Munro wrote:
Hello,
Since commit cdf91edb (2012), nodeIndexonlyscan.c says:
/*
* Predicate locks for index-only scans must be
acquired at the page
* level when the heap is not accessed, since
tuple-level predicate
Hello,
Since commit cdf91edb (2012), nodeIndexonlyscan.c says:
/*
* Predicate locks for index-only scans must be
acquired at the page
* level when the heap is not accessed, since
tuple-level predicate
* locks need the tuple's xmin
15 matches
Mail list logo
