Isn't the Postpone function intended and suitable for this kind of use case?

Yes, but I wonder if there is a better way of doing this, without using Postpone.

By the way, I noticed that after rescheduling I get cards with R much higher than my requested R, which is 0.8 for all my decks.

To list the options:

1. Without FSRS4Anki:
   1. Set review sort order to “relative overdueness”,
   2. optionally set the deck option Maximum reviews/day,
   3. then work off the backlog little by little, reviewing however many cards you can per day.
2. Without the Postpone feature:
   1. Temporarily set the requested retention to a lower value,
   2. then reschedule.
3. Manual postpone.
4. Automatic Postpone after rescheduling, until a certain number of cards is reached.
   • This would yet need to be implemented.
   • It is similar to the deck setting Maximum reviews/day. Therefore, it should just use the number set in Maximum reviews/day in the (rare) case that the user has set it.
   • Otherwise, the developers would need to set either
     • a hard maximum and immediately postpone the excess
     • or a threshold where the Helper will ask the user whether and how many cards they want to Postpone:

       FSRS4Anki Helper has detected that rescheduling results in a large backlog of [n] cards. This can happen, especially when using the rescheduler for the first time.
       Would you like to postpone some of the due cards to later dates?
       Postpone |___| cards
       |___OK___| |_Cancel_|

I would suggest @L-M-Sherlock to also make visible on ankiweb and in the FAQ how the user should deal with backlog.

@Expertium, could you rename this issue to something more specific, such as Deal with backlog? (I had a bit of trouble finding it.)

Automatic Postpone after rescheduling, until a certain number of cards is reached.

• This would yet need to be implemented.

• It is similar to the deck setting Maximum reviews/day. Therefore, it should just use the number set in Maximum reviews/day in the (rare) case that the user has set it.

• Otherwise, the developers would need to set either

  • a hard maximum and immediately postpone the excess
  • or a threshold where the Helper will ask the user whether and how many cards they want to Postpone:

    FSRS4Anki Helper has detected that rescheduling results in a large backlog of [n] cards. This can happen, especially when using the rescheduler for the first time.
    Would you like to postpone some of the due cards to later dates?
    Postpone |___| cards
    |OK| |Cancel|

@L-M-Sherlock I support this idea. As for what is considered "large", how about burden (after rescheduling)*2? If the backlog is greater than that, then this message should appear.

In my opinion, the better way to handle backlogs is to work it off little by little, reviewing as many cards as possible per day. So, I don't use the postpone function for dealing with backlogs.

The reason is that the postpone function increases the interval of the card by a specific multiplication factor, which may even result in an increment of greater than a month for cards with long intervals. But, when I clear backlogs by doing as many cards as possible per day, I am usually able to clear all of it within 10 days. So, using the postpone function would mean that clearing the backlog completely would take longer as compared to not using the postpone function.

But, of course, this is my way of thinking about the problem. Others may or may not agree with it.

Also, to ensure that I do those cards first that are at the highest risk of forgetting, I use "Relative Overdueness" as the review sort order while dealing with backlogs.

I prefer the method proposed by @user1823. Postpone just sweeps the problem under the rug. But I also agree that backlog will induce mental pressure. I think if we can set the default sorting of Anki to "Relative Overdueness", the problem could be solved easily via collaborating with setting the "Maximum reviews/day".

So do you plan to implement a new setting, "Maximum reviews/day", into the scheduler?

So do you plan to implement a new setting, "Maximum reviews/day", into the scheduler?

This option is already there in the Anki deck options.

Yes, but I was asking whether Sherlock is planning to add it to FSRS in a way that overrides Anki's built-in setting, just like FSRS's max interval overrides Anki's max interval.

I think that Sherlock means to say that we can advise users to set the review sort order to "Relative Overdueness" and adjust the "Maximum reviews/day" in the Deck Options when faced with a backlog.

Perhaps, we should add this advice to a message box that appears after rescheduling if the backlog is greater than a certain value (as @galantra suggested) but without asking the user to postpone the cards (because we deemed it to be not very useful). The threshold for such popup to appear can be taken as burden (after rescheduling) × 2 (as @Expertium suggested).

Adding this advice to a popup appearing just after rescheduling seems to be a good way to inform the user as compared to adding this advice somewhere else (for e.g. the FAQs).

I think we may need a new feature similar to Postpone, but targeting a specific number of reviews/day.
@L-M-Sherlock here is my idea: call the new feature "Dilute" (yes, stolen from SuperMemo again). It should change intervals in a way that makes the number of reviews/day for the next several days equal to or lower than the current value of Burden.
Say, currently burden=100, but the user has 500 due cards. Dilute should change their intervals in such a way that today (and for n more days) the number of due cards will be 100 or less. Note that it should be able to affect cards that aren't due today, but will become due within the next n days. In other words, Postpone only postpones cards that are due today, but Dilute postpones other cards too, cards that would be due tomorrow or the day after tomorrow. Sorry, but I don't have a precise step-by-step description of an algorithm that will actually do this.
Unfortunately, this can be even more detrimental to the schedule than Postpone, if used too often. Also, I think it's time we implement per-deck priority. That way low priority material will be postponed more, and high priority material will be postponed less.

By the way, I noticed that after rescheduling I get cards with R much higher than my requested R, which is 0.8 for all my decks.

That R value is retrievability for the specific card, not your requested retention.

When rescheduling occurs, cards with retrievability significantly higher than requested retention shouldn't be due. Sure, a little bit of it can happen due to siblings dispersion and load balancing, but not to the point where I have like 100 cards with retrievability being much higher than requested retention. For example, my requested retention is 0.8, and if I got 5 cards with R=80-85%, that would be fine. Getting 100 cards with R>90% when requested R is 0.8 is definitely not intended behaviour.

Just a reminder to do this: #175 (comment)

But, there are some new points to consider. So, it is not recommended to start working on this until these points are discussed.

As we saw in https://www.reddit.com/r/Anki/comments/16d56xp/spits_coffee/, the burden can also be quite large.

So, we probably need a different cutoff. Probably, 1.75 × average daily review load in the past week.

In the linked case, the problem was the retention i.e., the user had a very low retention before switching to FSRS and the target retention was high.

So, probably, if the the above cutoff (1.75 × average review load) is exceeded, we can compare the true retention in the past week with the target retention. If the target retention is more than 10% higher than the past true retention, we can warn the user.

What's the status of this issue?

This feature is now not as important as it once was because we advise against rescheduling all cards on switching to FSRS.

However, it would still be a "good to have" feature.

I think it is a "good to have" feature in Anki because the native feature is more popular than the add-on.

I think it is a "good to have" feature in Anki

I think that you are right. So, maybe we should add a feature request on Anki Forums.

how about a mix of postpone and flatten to deal with backlog such that the user suggests a maximum value for burden and the backlog is dispersed to future days without affecting cards due on that day.
e.g. user sets max burden as 700 and the number of cards forwarded to that day from backlog is 700 minus the number of cards due on that day.
for context, i recently increased retention rate which made 9k cards due and i usually deal with backlog in a manner similar to one described above.