user15223: As I understand it, 8-piece endgame tablebases have been in development for many years. The big issue is the sheer number of positions that are possible.
Are there any attempts at making a "practical" endgame tablebase, where the search is only over positions that might matter in actual games? For example, a KQQQ vs KB endgame is a 6-piece position, but it's trivial for the side with three queens to win even without a tablebase, so one should not need to devote actual computing power to solving it. Yes, there might be exceptions, but they would be so rare that focusing on the much more interesting and practically important endgames (e.g. KQP vs KRB) would be more productive.

user17425: It is difficult to define the exact boundary of practical vs. impractical.  However, you can define this for yourself.
See this project
You can decide what you want to generate like:

rtbgen KQRvKR

However, as Remellion mentioned, there is a dependency between the different tables.  For KQRvKR to function you will also need KQvKR, KRvKR and others so you would have to manage that yourself.  I used this to create a pawn only table base since I didn't want to keep a full 6 or 7 piece tablebase.

user11144: The answers given already should convince you it is not easy to concentrate on "practical". The case is not completely hopeless, though: if two of the pieces are pawns on the same line, chance is good that - while surely they can eat a piece - most optimal lines keep them there, greatly reducing the amount of computation.
FINALGEN tablebase generator -
A practical peek

user15989: There is a contradiction in terms in "only" generating practical endgame tablebases. We have to understand how tablebases are generated to see why.
Tablebases are generated by working backwards from the final mating/drawing positions, "retracting" moves rather than playing them forward. First, every possible final position is exhaustively listed. Then from each, we "retract" (take back) moves that could have been played. In doing so, we know a possible outcome of the resulting position (by playing forward to the final position again). Do this for all positions, and we know the ideal outcome of all of them.
Now what is a retraction? Pieces move backwards, so everything moves as in normal chess except pawns. Pieces can uncapture other pieces, leaving an extra piece on the board. Notably, pieces can unpromote into pawns.
Herein lies the problem. If you want to evaluate the "practical" endgames, you need to know all the final positions that could lead to them by retractions. If we agree KPPP v KB is a practical endgame (seems so), then we need to know the outcome of all KQQQ v KB endgames, since it might be the case that the only winning line is to reach a winning KQQQ v KB endgame. It is necessary to do these "trivial" endgames in order to do the practical ones.
(Preemptive counter-counterargument: not all KQQQ v KB positions are winning. Think of stalemates. This is another reason why we cannot handwave and say "all positions with this material balance are winning".)
Furthermore, the absurd KQQQ v KB might be necessary to correctly generate results for KQPP v KQBP or some dramatic pawn race endgame. If you don't check all the possible final positions (even absurd ones), you can never be sure that you didn't miss the only winning/drawing line.
The only possible "optimisation" of this sort you can do is to not generate, say K+6 v K endgames (which I think was the case for the 7-men tables, they skipped K+5 v K until everything else was done.)

15223: <p>As I understand it, <a href="https://en.wikipedia.org/wiki/Endgame_tablebase#Computer_chess" rel="noreferrer">8-piece endgame tablebases</a> have been in development for many years. The big issue is the sheer number of positions that are possible.</p>

<p>Are there any attempts at making a "practical" endgame tablebase, where the search is only over positions that might matter in actual games? For example, a KQQQ vs KB endgame is a 6-piece position, but it's trivial for the side with three queens to win even without a tablebase, so one should not need to devote actual computing power to solving it. Yes, there might be exceptions, but they would be so rare that focusing on the much more interesting and practically important endgames (e.g. KQP vs KRB) would be more productive.</p>
 17425: <p>It is difficult to define the exact boundary of practical vs. impractical.  However, you can define this for yourself.</p>

<p>See <a href="https://github.com/syzygy1/tb" rel="nofollow noreferrer">this project</a></p>

<p>You can decide what you want to generate like:</p>

<blockquote>
  <p>rtbgen KQRvKR</p>
</blockquote>

<p>However, as Remellion mentioned, there is a dependency between the different tables.  For KQRvKR to function you will also need KQvKR, KRvKR and others so you would have to manage that yourself.  I used this to create a pawn only table base since I didn't want to keep a full 6 or 7 piece tablebase.</p>
 11144: <p>The answers given already should convince you it is not easy to concentrate on &quot;practical&quot;. The case is not <em>completely</em> hopeless, though: if two of the pieces are pawns on the same line, chance is good that - while surely they can eat a piece - most optimal lines keep them there, greatly reducing the amount of computation.
<a href="https://finalgenchess.pagesperso-orange.fr/" rel="nofollow noreferrer">FINALGEN tablebase generator</a> -
<a href="http://www.arves.org/arves/index.php/nl/halloffame/2-ongecategoriseerd/1533-8-men-tablebase-explorations-opposing-1-pawn-endgames" rel="nofollow noreferrer">A practical peek</a></p>
 15989: <p>There is a contradiction in terms in "only" generating practical endgame tablebases. We have to understand how tablebases are generated to see why.</p>

<p>Tablebases are generated by working backwards from the final mating/drawing positions, "retracting" moves rather than playing them forward. First, every possible final position is exhaustively listed. Then from each, we "retract" (take back) moves that could have been played. In doing so, we know a possible outcome of the resulting position (by playing forward to the final position again). Do this for all positions, and we know the ideal outcome of all of them.</p>

<p>Now what is a retraction? Pieces move backwards, so everything moves as in normal chess except pawns. Pieces can uncapture other pieces, leaving an extra piece on the board. Notably, <em>pieces can unpromote into pawns</em>.</p>

<p>Herein lies the problem. <strong>If you want to evaluate the "practical" endgames, you need to know all the final positions that could lead to them by retractions</strong>. If we agree KPPP v KB is a practical endgame (seems so), then we need to know the outcome of <em>all</em> KQQQ v KB endgames, since it might be the case that the only winning line is to reach a winning KQQQ v KB endgame. It is necessary to do these "trivial" endgames in order to do the practical ones.</p>

<p>(Preemptive counter-counterargument: not all KQQQ v KB positions are winning. Think of stalemates. This is another reason why we cannot handwave and say "all positions with this material balance are winning".)</p>

<p>Furthermore, the absurd KQQQ v KB might be necessary to correctly generate results for KQPP v KQBP or some dramatic pawn race endgame. If you don't check all the possible final positions (even absurd ones), you can never be sure that you didn't miss the only winning/drawing line.</p>

<p>The only possible "optimisation" of this sort you can do is to not generate, say K+6 v K endgames (which I think was the case for the 7-men tables, they skipped K+5 v K until everything else was done.)</p>
