Peter Geoghegan writes:
> On Thu, Nov 7, 2024 at 7:38 PM Andy Fan wrote:
>> If the delete goes with Index Scan of t_b_idx, we still have the chances
>> to mark hints on t_b_idx, so that it can be useful during index split?
>
> The exact rules for when LP_DEAD bits are set are a bit complicated,
On Thu, Nov 7, 2024 at 7:38 PM Andy Fan wrote:
> If the delete goes with Index Scan of t_b_idx, we still have the chances
> to mark hints on t_b_idx, so that it can be useful during index split?
See for yourself, by using pageinspect. The bt_page_items function
returns a "dead" column, which will
On Thu, Nov 7, 2024 at 7:31 PM Andy Fan wrote:
> With the (1) (2) (3), only non-hot UPDATE is considered.
>
> Then why do we need "unchanged index" as a prerequisite?
How else is the nbtree code ever supposed to know when it might be a
good idea to do a bottom-up index deletion pass? You could do
Andy Fan writes:
> (3). DELETE does generate new index entry, but we might not touch
> the indexes at all during deletes (*except the index we used for index
> scan*).
I still not check the code right now (it may still take times for me
even I understand the overall design). So do we need to mar
Peter Geoghegan writes:
Hi Peter,
I think I understand the main idea now with your help, I'd like to
repeat my understanding for your double check.
> On Thu, Nov 7, 2024 at 3:05 AM Andy Fan wrote:
>> So my questions are: (a) How does the "logically unchanged index" hint
>> can be helpful for
Hi Andy,
On Thu, Nov 7, 2024 at 3:05 AM Andy Fan wrote:
> So my questions are: (a) How does the "logically unchanged index" hint
> can be helpful for this purpose?
It's the main trigger for bottom-up index deletion. It is taken as a
signal that the leaf page might have garbage duplicates from no
Hi Peter,
Sorry for bringing up so old thread since I have some troubles to
understand what is going on here. I'd start with something I can
understand then raise my question I have right now.
>
> The difference here is that we're simply making an intelligent guess
> -- there have been no index
On Mon, Jan 25, 2021 at 10:48 PM Amit Kapila wrote:
> I need to spend more time on benchmarking to study the behavior and I
> think without that it would be difficult to make a conclusion in this
> regard. So, let's not consider any action on this front till I spend
> more time to find the details
On Sat, Jan 23, 2021 at 5:27 AM Peter Geoghegan wrote:
>
> On Thu, Jan 21, 2021 at 9:23 PM Amit Kapila wrote:
> > > Slowing down non-HOT updaters in these extreme cases may actually be a
> > > good thing, even when bottom-up deletion finally becomes ineffective.
> > > It can be thought of as back
On Thu, Jan 21, 2021 at 9:23 PM Amit Kapila wrote:
> > Slowing down non-HOT updaters in these extreme cases may actually be a
> > good thing, even when bottom-up deletion finally becomes ineffective.
> > It can be thought of as backpressure. I am not worried about slowing
> > down something that i
On Thu, Jan 21, 2021 at 12:23 AM Peter Geoghegan wrote:
>
> On Wed, Jan 20, 2021 at 5:33 AM Amit Kapila wrote:
> > > Victor independently came up with a benchmark that ran over several
> > > hours, with cleanup consistently held back by ~5 minutes by a long
> > > running transaction:
> > >
> >
>
On Wed, Jan 20, 2021 at 10:53 AM Peter Geoghegan wrote:
> This patch is unusual in that you really need to think about emergent
> behaviors to understand it. That is certainly a difficult thing to do,
> and it's understandable that even an expert might not grok it without
> considering it carefull
On Wed, Jan 20, 2021 at 5:33 AM Amit Kapila wrote:
> > Victor independently came up with a benchmark that ran over several
> > hours, with cleanup consistently held back by ~5 minutes by a long
> > running transaction:
> >
>
> AFAICS, the long-running transaction used in the test is below:
> SELEC
On Wed, Jan 20, 2021 at 10:50 AM Andres Freund wrote:
>
> Hi,
>
> On 2021-01-20 09:24:35 +0530, Amit Kapila wrote:
> > I feel extending the deletion mechanism based on the number of LP_DEAD
> > items sounds more favorable than giving preference to duplicate
> > items. Sure, it will give equally go
On Wed, Jan 20, 2021 at 7:03 PM Amit Kapila wrote:
>
> On Wed, Jan 20, 2021 at 10:58 AM Peter Geoghegan wrote:
> >
> > On Tue, Jan 19, 2021 at 7:54 PM Amit Kapila wrote:
> > > The worst cases could be (a) when there is just one such duplicate
> > > (indexval logically unchanged) on the page and
On Wed, Jan 20, 2021 at 10:58 AM Peter Geoghegan wrote:
>
> On Tue, Jan 19, 2021 at 7:54 PM Amit Kapila wrote:
> > The worst cases could be (a) when there is just one such duplicate
> > (indexval logically unchanged) on the page and that happens to be the
> > last item and others are new insertio
On Tue, Jan 19, 2021 at 7:54 PM Amit Kapila wrote:
> The worst cases could be (a) when there is just one such duplicate
> (indexval logically unchanged) on the page and that happens to be the
> last item and others are new insertions, (b) same as (a) and along
> with it lets say there is an open t
Hi,
On 2021-01-20 09:24:35 +0530, Amit Kapila wrote:
> I feel extending the deletion mechanism based on the number of LP_DEAD
> items sounds more favorable than giving preference to duplicate
> items. Sure, it will give equally good or better results if there are
> no long-standing open transactio
On Tue, Jan 19, 2021 at 3:03 AM Peter Geoghegan wrote:
>
> On Mon, Jan 18, 2021 at 1:10 PM Victor Yegorov wrote:
> > I must admit, that it's a bit difficult to understand you here (at least
> > for me).
> >
> > I assume that by "bet" you mean flagged tuple, that we marked as such
> > (should we
On Mon, Jan 18, 2021 at 1:10 PM Victor Yegorov wrote:
> I must admit, that it's a bit difficult to understand you here (at least for
> me).
>
> I assume that by "bet" you mean flagged tuple, that we marked as such
> (should we implement the suggested case).
> As heapam will give up early in case
пн, 18 янв. 2021 г. в 21:43, Peter Geoghegan :
> In the end, I couldn't justify imposing this cost on anything other
> than a non-HOT updater, which is what the flag proposal would require
> me to do -- then it's not 100% clear that the relative cost of each
> "bet" placed in heapam.c really is ex
On Mon, Jan 18, 2021 at 6:11 AM Victor Yegorov wrote:
> If I understand you correctly, you suggest to track _all_ the hints that came
> from the executor for possible non-HOT logical duplicates somewhere on
> the page. And when we hit the no-space case, we'll check not only the last
> item being h
On Sun, Jan 17, 2021 at 10:44 PM Amit Kapila wrote:
> With the above example, it seems like it would also help when this is not
> true.
I'll respond to your remarks here separately, in a later email.
> I am not sure what I proposed fits here but the bottom-up sounds like
> we are starting from
пн, 18 янв. 2021 г. в 13:42, Amit Kapila :
> I don't think any of these can happen in what I am actually saying. Do
> you still have the same feeling after reading this email? Off-hand, I
> don't see any downsides as compared to the current approach and it
> will have fewer splits in some other wo
On Mon, Jan 18, 2021 at 5:11 PM Victor Yegorov wrote:
>
> пн, 18 янв. 2021 г. в 07:44, Amit Kapila :
>>
>> The summary of the above is that with Case-1 (clean-up based on hint
>> received with the last item on the page) it takes fewer operations to
>> cause a page split as compared to Case-2 (clea
пн, 18 янв. 2021 г. в 07:44, Amit Kapila :
> The summary of the above is that with Case-1 (clean-up based on hint
> received with the last item on the page) it takes fewer operations to
> cause a page split as compared to Case-2 (clean-up based on hint
> received with at least of the items on the
On Mon, Jan 18, 2021 at 12:43 AM Peter Geoghegan wrote:
>
> On Sat, Jan 16, 2021 at 9:55 PM Amit Kapila wrote:
> > Do we do this optimization (bottom-up deletion) only when the last
> > item which can lead to page split has indexUnchanged set to true? If
> > so, what if the last tuple doesn't hav
On Sat, Jan 16, 2021 at 9:55 PM Amit Kapila wrote:
> Do we do this optimization (bottom-up deletion) only when the last
> item which can lead to page split has indexUnchanged set to true? If
> so, what if the last tuple doesn't have indexUnchanged but the
> previous ones do have?
Using the indexU
On Wed, Jan 13, 2021 at 11:16 PM Peter Geoghegan wrote:
>
> On Mon, Jan 11, 2021 at 9:26 PM Peter Geoghegan wrote:
> > I'm going to proceed with committing the original version of the patch
> > -- I feel that this settles it.
>
> Pushed both patches from the patch series just now.
>
Nice work! I
On Mon, Jan 11, 2021 at 9:26 PM Peter Geoghegan wrote:
> I'm going to proceed with committing the original version of the patch
> -- I feel that this settles it.
Pushed both patches from the patch series just now.
Thanks for the code reviews and benchmarking work!
--
Peter Geoghegan
On Sun, Jan 10, 2021 at 4:06 PM Peter Geoghegan wrote:
> Attached is v13, which has this tweak, and other miscellaneous cleanup
> based on review from both Victor and Heikki. I consider this version
> of the patch to be committable. I intend to commit something close to
> it in the next week, prob
пн, 11 янв. 2021 г. в 22:10, Peter Geoghegan :
> I imagine that this happened because you have track_io_timing=on in
> postgresql.conf. Doesn't the same failure take place with the current
> master branch?
>
> I have my own way of running the locally installed Postgres when I
> want "make installc
On Mon, Jan 11, 2021 at 12:19 PM Victor Yegorov wrote:
> (see attached diff). It doesn't look like the fault of this patch, though.
>
> I suppose you plan to send another revision before committing this.
> Therefore I didn't perform any tests here, will wait for the next version.
I imagine that t
пн, 11 янв. 2021 г. в 01:07, Peter Geoghegan :
>
> Attached is v13, which has this tweak, and other miscellaneous cleanup
> based on review from both Victor and Heikki. I consider this version
> of the patch to be committable. I intend to commit something close to
> it in the next week, probably n
On Mon, Jan 4, 2021 at 8:28 AM Victor Yegorov wrote:
> I've looked through the v12 patch.
>
> I like the new outline:
>
> - _bt_delete_or_dedup_one_page() is the main entry for the new code
> - first we try _bt_simpledel_pass() does improved cleanup of LP_DEAD entries
> - then (if necessary) _bt_b
On Mon, Jan 4, 2021 at 4:08 AM Heikki Linnakangas wrote:
> You said above that heap_tid_shellsort() is very performance critical,
> and that's why you use the two arrays approach. If it's so performance
> critical that swapping 8 bytes vs 12 byte array elements makes a
> difference, I would guess
чт, 31 дек. 2020 г. в 03:55, Peter Geoghegan :
> Attached is v12, which fixed bitrot against the master branch. This
> version has significant comment and documentation revisions. It is
> functionally equivalent to v11, though.
>
> I intend to commit the patch in the next couple of weeks. While it
On 02/12/2020 00:18, Peter Geoghegan wrote:
On Tue, Dec 1, 2020 at 1:50 AM Heikki Linnakangas wrote:
On 30/11/2020 21:50, Peter Geoghegan wrote:
+} TM_IndexDelete;
+} TM_IndexStatus;
Is it really significantly faster to have two arrays? If you had just
one array, each element would be on
On Thu, Dec 31, 2020 at 11:01 AM Zhihong Yu wrote:
> Happy New Year.
Happy New Year.
> For v12-0001-Pass-down-logically-unchanged-index-hint.patch
>
> + if (hasexpression)
> + return false;
> +
> + return true;
>
> The above can be written as return !hasexpression;
> The negation is du
чт, 31 дек. 2020 г. в 20:01, Zhihong Yu :
> For v12-0001-Pass-down-logically-unchanged-index-hint.patch
>
> + if (hasexpression)
> + return false;
> +
> + return true;
>
> The above can be written as return !hasexpression;
>
To be honest, I prefer the way Peter has it in his patch.
Yes,
Hi, Peter:
Happy New Year.
For v12-0001-Pass-down-logically-unchanged-index-hint.patch
+ if (hasexpression)
+ return false;
+
+ return true;
The above can be written as return !hasexpression;
The negation is due to the return value from
index_unchanged_by_update_var_walker() is inverse
чт, 31 дек. 2020 г. в 03:55, Peter Geoghegan :
> Attached is v12, which fixed bitrot against the master branch. This
> version has significant comment and documentation revisions. It is
> functionally equivalent to v11, though.
>
> I intend to commit the patch in the next couple of weeks. While it
On Wed, Dec 9, 2020 at 5:12 PM Peter Geoghegan wrote:
> Most of the real changes in v11 (compared to v10) are in heapam.c.
> I've completely replaced the table_compute_xid_horizon_for_tuples()
> interface with a new interface that supports all existing requirements
> (from index deletions that sup
Hi,
In v11-0001-Pass-down-logically-unchanged-index-hint.patch :
+ if (hasexpression)
+ return false;
+
+ return true;
The above can be written as 'return !hasexpression;'
For +index_unchanged_by_update_var_walker:
+ * Returns true when Var that appears within allUpdatedCols located.
On Tue, Dec 1, 2020 at 1:50 AM Heikki Linnakangas wrote:
> This is a wholly new concept with a lot of heuristics. It's a lot of
> swallow.
Thanks for taking a look! Yes, it's a little unorthodox.
Ideally, you'd find time to grok the patch and help me codify the
design in some general kind of way
This is a wholly new concept with a lot of heuristics. It's a lot of
swallow. But here are a few quick comments after a first read-through:
On 30/11/2020 21:50, Peter Geoghegan wrote:
+/*
+ * State used when calling table_index_delete_check() to perform "bottom up"
+ * deletion of duplicate ind
On Wed, Nov 25, 2020 at 1:20 PM Victor Yegorov wrote:
> In the _bt_delete_or_dedup_one_page() we start with the simple loop over
> items on the page and
> if there're any LP_DEAD tuples, we're kicking off _bt_delitems_delete().
Right.
> So if I understood you right, you plan to make this loop (
ср, 25 нояб. 2020 г. в 19:41, Peter Geoghegan :
> We have promising tuples for bottom-up deletion. Why not have
> "promising heap blocks" for traditional LP_DEAD index tuple deletion?
> Or if you prefer, we can consider index tuples that *don't* have their
> LP_DEAD bits set already but happen to
On Wed, Nov 25, 2020 at 4:43 AM Victor Yegorov wrote:
>> Then I had a much better idea: Make the existing LP_DEAD stuff a
>> little more like bottom-up index deletion. We usually have to access
>> heap blocks that the index tuples point to today, in order to have a
>> latestRemovedXid cutoff (to g
ср, 25 нояб. 2020 г. в 05:35, Peter Geoghegan :
> Then I had a much better idea: Make the existing LP_DEAD stuff a
> little more like bottom-up index deletion. We usually have to access
> heap blocks that the index tuples point to today, in order to have a
> latestRemovedXid cutoff (to generate re
On Tue, Nov 17, 2020 at 12:45 PM Peter Geoghegan wrote:
> > I am thinking of two more scenarios that require testing:
> > - queue in the table, with a high rate of INSERTs+DELETEs and a long
> > transaction.
>
> I see your point. This is going to be hard to make work outside of
> unique indexes,
On Tue, Nov 17, 2020 at 7:24 AM Victor Yegorov wrote:
> I've looked through the code and it looks very good from my end:
> - plenty comments, good description of what's going on
> - I found no loose ends in terms of AM integration
> - magic constants replaced with defines
> Code looks good. Still,
On Tue, Nov 17, 2020 at 9:19 AM Victor Yegorov wrote:
> OK. Can you explain what deprecation means here?
> If this functionality is left as is, it is not really deprecation?..
It just means that we only keep it around for compatibility purposes.
We would like to remove it, but can't right now. If
вт, 17 нояб. 2020 г. в 17:24, Peter Geoghegan :
> I prefer to continue to maintain the flag in the same way, regardless
> of which B-Tree version is in use (i.e. if it's heapkeyspace or not).
> Maintaining the flag is not expensive, may have some small value for
> forensic or debugging purposes, a
On Tue, Nov 17, 2020 at 7:05 AM Victor Yegorov wrote:
> I've looked over the BTP_HAS_GARBAGE modifications, they look sane.
> I've double checked that heapkeyspace indexes don't use this flag (don't rely
> on it),
> while pre-v4 ones still use it.
Cool.
> I have a question. This flag is raised
пт, 13 нояб. 2020 г. в 00:01, Peter Geoghegan :
> Attached is v8, which has the enhancements for low cardinality data
> that I mentioned earlier today. It also simplifies the logic for
> dealing with posting lists that we need to delete some TIDs from.
> These posting list simplifications also mak
чт, 12 нояб. 2020 г. в 23:00, Peter Geoghegan :
> Another thing that I'll probably add to v8: Prefetching. This is
> probably necessary just so I can have parity with the existing
> heapam.c function that the new code is based on,
> heap_compute_xid_horizon_for_tuples(). That will probably help he
чт, 12 нояб. 2020 г. в 23:00, Peter Geoghegan :
> It would be helpful if you could take a look at the nbtree patch --
> particularly the changes related to deprecating the page-level
> BTP_HAS_GARBAGE flag. I would like to break those parts out into a
> separate patch, and commit it in the next we
On Sun, Nov 15, 2020 at 2:29 PM Victor Yegorov wrote:
> TPS
> ---
> query | Master TPS | Patched TPS | diff
> ++-+---
> UPDATE + SELECT | 2413 |2473 | +2.5%
> 3 SELECT in txn | 19737 | 19545 | -0.9%
> 15min SELECT|
On Thu, Nov 12, 2020 at 3:00 PM Peter Geoghegan wrote:
> Attached is v8, which has the enhancements for low cardinality data
> that I mentioned earlier today. It also simplifies the logic for
> dealing with posting lists that we need to delete some TIDs from.
> These posting list simplifications a
On Wed, Nov 11, 2020 at 6:17 AM Victor Yegorov wrote:
> I've looked at the latest (v7) patchset.
> I've decided to use a quite common (in my practice) setup with an indexed
> mtime column over scale 1000 set:
Thanks for testing!
> We can see that:
> - unused index is not suffering from not-HOT
On Thu, Oct 29, 2020 at 4:30 PM Peter Geoghegan wrote:
> I found that the "fiver" and "tenner" indexes in particular took a
> very long time to have even one page split with a long running
> transaction. Another interesting effect was that all page splits
> suddenly stopped when my one hour 30 mi
On Thu, Oct 29, 2020 at 3:05 PM Victor Yegorov wrote:
> And some more comments after another round of reading the patch.
>
> 1. Looks like UNIQUE_CHECK_NO_WITH_UNCHANGED is used for HOT updates,
>should we use UNIQUE_CHECK_NO_HOT here? It is better understood like this.
This would probably ge
On Wed, Oct 28, 2020 at 4:05 PM Victor Yegorov wrote:
> I've reviewed v5 of the patch and did some testing.
Thanks!
> I now see what you mean by saying that this patch is a natural and logical
> extension of the deduplication v13 work. I agree with this.
I tried the patch out with a long runnin
пн, 26 окт. 2020 г. в 22:15, Peter Geoghegan :
> Attached is v5, which has changes that are focused on two important
> high level goals:
>
And some more comments after another round of reading the patch.
1. Looks like UNIQUE_CHECK_NO_WITH_UNCHANGED is used for HOT updates,
should we use UNIQU
On Tue, Oct 27, 2020 at 2:44 AM Simon Riggs wrote:
> While it is important we investigate the worst cases, I don't see this
> is necessarily bad.
I looked at "perf top" a few times when the test from yesterday ran. I
saw that the proposed delete mechanism was the top consumer of CPU
cycles. It se
On Mon, 26 Oct 2020 at 21:15, Peter Geoghegan wrote:
> Now for the not-so-good news. The TPS numbers looked like this
> (results in original chronological order of the runs, which I've
> interleaved):
While it is important we investigate the worst cases, I don't see this
is necessarily bad.
HOT
On Sat, Oct 24, 2020 at 2:55 AM Simon Riggs wrote:
> The problem I highlighted is that the average UPDATE latency is x2
> what it is on current HEAD. That is not consistent with the reported
> TPS, so it remains an issue and that isn't obvious.
Why do you say that? I reported that the UPDATE late
On Fri, 23 Oct 2020 at 18:14, Peter Geoghegan wrote:
> It's obvious that a page split is more expensive than the delete
> operation (when it works out).
The problem I highlighted is that the average UPDATE latency is x2
what it is on current HEAD. That is not consistent with the reported
TPS, so
On Fri, Oct 23, 2020 at 9:03 AM Simon Riggs wrote:
> Please publish details of how long a pre-split cleaning operation
> takes and what that does to transaction latency. It *might* be true
> that the cost of avoiding splits is worth it in balance against the
> cost of splitting, but it might not.
On Thu, 22 Oct 2020 at 18:42, Peter Geoghegan wrote:
> > The average latency is x2. What is the distribution of latencies?
> > Occasional very long or all uniformly x2?
>
> The latency is generally very even with the patch. There is a constant
> hum of cleanup by the new mechanism in the case of
On Thu, Oct 22, 2020 at 10:12 AM Simon Riggs wrote:
> > 18,988.762398 TPS for the patch
> > 11,123.551707 TPS for the master branch.
>
> Very good.
I'm happy with this result, but as I said it's not really the point. I
can probably get up to a 5x or more improvement in TPS if I simply add
enough
On Fri, 16 Oct 2020 at 20:12, Peter Geoghegan wrote:
> The TPS/throughput is about what you'd expect for the two hour run:
>
> 18,988.762398 TPS for the patch
> 11,123.551707 TPS for the master branch.
Very good.
> Patch:
>
> statement latencies in milliseconds:
> 0.294 UPDATE pgbench
On Wed, Oct 21, 2020 at 3:36 PM Peter Geoghegan wrote:
> Bear in mind that we actually do practically the same thing all the
> time with the current LP_DEAD setting stuff, where we need to call
> compute_xid_horizon_for_tuples/heap_compute_xid_horizon_for_tuples
> with a leaf buffer lock held in a
On Wed, Oct 21, 2020 at 8:25 AM Robert Haas wrote:
> That certainly isn't great. I mean, it might be not be too terrible,
> because it's a leaf index page isn't nearly as potentially hot as a VM
> page or a clog page, but it hurts interruptibility and risks hurting
> concurrency, but if it were po
On Wed, Oct 7, 2020 at 7:48 PM Peter Geoghegan wrote:
> To be blunt: It may be controversial that we're accessing multiple
> heap pages while holding an exclusive lock on a leaf page, in the
> hopes that we can avoid a page split, but without any certainty that
> it'll work out.
That certainly is
On Fri, Oct 16, 2020 at 1:58 PM Peter Geoghegan wrote:
> Attached is v3, which is rebased against the master branch as of
> today. No real changes, though.
And now here's v4.
This version adds handling of posting list tuples, which I was
skipping over before. Highly contended leaf pages with pos
On Fri, Oct 16, 2020 at 1:00 PM Victor Yegorov wrote:
> I really like these results, great work!
Thanks Victor!
> I'm also wondering how IO numbers changed due to these improvements,
> shouldn't be difficult to look into.
Here is the pg_statio_user_indexes for patch for the same run:
scheman
пт, 16 окт. 2020 г. в 21:12, Peter Geoghegan :
> I ran the script for two hours and 16 clients with the patch, then for
> another two hours with master. After that time, all 3 indexes were
> exactly the same size with the patch, but had almost doubled in size
> on master:
>
> aid_pkey_include_abal
On Wed, Oct 14, 2020 at 7:40 AM Peter Geoghegan wrote:
> Right. The trick is to pay only a fixed low cost (maybe as low as one
> heap page access) when we start out, and ratchet it up only if the
> first heap page access looks promising.
Just as an example of how the patch can help, consider the
On Wed, Oct 14, 2020 at 7:07 AM Anastasia Lubennikova
wrote:
> The idea seems very promising, especially when extended to handle non-unique
> indexes too.
Thanks!
> That's exactly what I wanted to discuss after the first letter. If we could
> make (non)HOT-updates index specific, I think it co
On 08.10.2020 02:48, Peter Geoghegan wrote:
On Tue, Jun 30, 2020 at 5:03 PM Peter Geoghegan wrote:
Attached is a POC patch that teaches nbtree to delete old duplicate
versions from unique indexes. The optimization targets non-HOT
duplicate version bloat. Although the patch is rather rough, it
n
On Mon, Oct 12, 2020 at 3:47 AM Andrey Borodin wrote:
> The idea looks very interesting.
> It resembles GiST microvacuum: GiST tries to vacuum single page before split.
AFAICT the GiST microvacuum mechanism is based on the one in nbtree,
which is based on setting LP_DEAD bits when index scans fin
> 8 окт. 2020 г., в 04:48, Peter Geoghegan написал(а):
>
> On Tue, Jun 30, 2020 at 5:03 PM Peter Geoghegan wrote:
>> Attached is a POC patch that teaches nbtree to delete old duplicate
>> versions from unique indexes. The optimization targets non-HOT
>> duplicate version bloat. Although the p
On Tue, Jun 30, 2020 at 5:03 PM Peter Geoghegan wrote:
> Attached is a POC patch that teaches nbtree to delete old duplicate
> versions from unique indexes. The optimization targets non-HOT
> duplicate version bloat. Although the patch is rather rough, it
> nevertheless manages to more or less eli
85 matches
Mail list logo
