On Fri, 1 Oct 2021 at 15:20, Jaime Casanova
wrote:
> This has been stalled since July, and based on Peter's comment i feel we
> should mark this as RwF. Which i'm doing now.
>
> Please feel free to resubmit for Next Commitfest.
Agreed, thank you Jaime.
--
Simon Riggshttp://www.
On Thu, Jul 01, 2021 at 09:22:38AM -0700, Peter Geoghegan wrote:
> On Thu, Jul 1, 2021 at 8:23 AM Simon Riggs
> wrote:
> > Definitely some good ideas here.
>
> I have been meaning to come up with some kind of solution to the
> problem of "self-blocking" LP_DEAD bit setting within the
> kill_prio
On Thu, Jul 1, 2021 at 8:23 AM Simon Riggs wrote:
> Definitely some good ideas here.
I have been meaning to come up with some kind of solution to the
problem of "self-blocking" LP_DEAD bit setting within the
kill_prior_tuple mechanism. It's hard to argue against that.
> I'm out of time to do any
On Fri, Jun 25, 2021 at 4:44 PM Peter Geoghegan wrote:
>
> On Fri, Jun 25, 2021 at 1:43 AM Simon Riggs
> wrote:
> > Seems a little bizarre to have _bt_check_unique() call back into the
> > heap block we literally just unpinned.
>
> I suppose it is a little bizarre.
>
> > This is another case of t
On Fri, Jun 25, 2021 at 1:43 AM Simon Riggs
wrote:
> Seems a little bizarre to have _bt_check_unique() call back into the
> heap block we literally just unpinned.
I suppose it is a little bizarre.
> This is another case of the UPDATE scan and later heap/index
> insertions not working together ve
On Fri, Jun 25, 2021 at 2:34 AM Peter Geoghegan wrote:
>
> On Thu, Jun 24, 2021 at 5:39 AM Simon Riggs
> wrote:
> > This case occurs when we are doing non-HOT UPDATEs. That command is
> > searched, so the scan will already have touched the heap and almost
> > certainly the index also, setting any
On Thu, Jun 24, 2021 at 5:39 AM Simon Riggs
wrote:
> This case occurs when we are doing non-HOT UPDATEs. That command is
> searched, so the scan will already have touched the heap and almost
> certainly the index also, setting any LP_DEAD bits already in the most
> frequent case.
But it won't, be
On Wed, Jun 23, 2021 at 5:42 PM Peter Geoghegan wrote:
>
> On Wed, Jun 23, 2021 at 9:31 AM Simon Riggs
> wrote:
> > You're right that skipping the check might also skip killing a prior
> > row version, but it doesn't prevent later scans from killing them, so
> > there is no correctness aspect to
On Wed, Jun 23, 2021 at 9:31 AM Simon Riggs
wrote:
> You're right that skipping the check might also skip killing a prior
> row version, but it doesn't prevent later scans from killing them, so
> there is no correctness aspect to that.
Probably not, no. I'll assume for now that there is no correc
On Wed, Jun 23, 2021 at 5:17 PM Peter Geoghegan wrote:
>
> On Mon, Jun 21, 2021 at 5:31 AM Simon Riggs
> wrote:
> > Seems like we can skip the uniqueness check if indexUnchanged, which
> > will speed up non-HOT UPDATEs on tables with B-Trees.
>
> I thought about doing this myself. Never got as fa
On Mon, Jun 21, 2021 at 5:31 AM Simon Riggs
wrote:
> Seems like we can skip the uniqueness check if indexUnchanged, which
> will speed up non-HOT UPDATEs on tables with B-Trees.
I thought about doing this myself. Never got as far as thinking about
the correctness implications in detail.
One thin
Seems like we can skip the uniqueness check if indexUnchanged, which
will speed up non-HOT UPDATEs on tables with B-Trees.
Passes tests.
Comments?
--
Simon Riggshttp://www.EnterpriseDB.com/
skip_nonHOT_btree_unique_check.v1.patch
Description: Binary data
12 matches
Mail list logo
