Matthias Kestenholz

Ah, yes. - Well, for the total descendants count, you can always query the root node of the current tree (using `node.ancestors()[0] if node.parent_id else node`) and then check `node.descendants().count()`...

The problem is then that tree queries will always build a tree of at least all descendants of the current node; you can apply a limit like (untested!) `.extra(where=["tree_depth

Hi @naomiaro Right now there isn't such a thing. It should be easy to add, do you want to take a stab at it?

Sure! I slightly prefer "path" these days but keeping the regex is fine too.

Yeah, you can do something like ```python from django.db.models.expressions import RawSQL Node.objects.with_tree_fields().values( tree_depth=RawSQL("tree_depth", ()), tree_path=RawSQL("tree_path", ()), ) ``` Note though that this only returns an array for `tree_path` when using...

Thanks! I haven't yet had the problem where trees became so big that the performance suffered too much. I have a list of interesting links stashed away, e.g. https://schinckel.net/2016/01/19/postgres-tree-shootout-part-3%3A-adjacency-list-using-views/ https://schinckel.net/2016/01/27/django-trees-via-closure-view/...

Ah, you're right. `descendants()` could indeed be optimized a lot. We'd need a way to modify this line in the PostgreSQL case: https://github.com/feincms/django-tree-queries/blob/d02c16cc5c07ccb37c78e76e0934c895e623b3af/tree_queries/compiler.py#L91 The `tree_filter` indeed does not help in...

Thinking out loud, I wonder if we could make an easy, non-intrusive fix just for this case, or if we should better pursue the materialized view optimization for very large...

Thanks for profiling this! Then it sounds like small fixes here and there would work well.

> I'm wondering; could this library be simplified if it leveraged django-cte? Alternatively, if this library focused on Materialized View representation of the trees, it would offer an potentially much...