Hierarchical Structures in PostgreSQL (2020)

Re:Hierarchical Structures in PostgreSQL (2020) by barrkel on Friday June 25, 2021 @08:56PM (#27638036)

Recursive CTEs are almost never what you want. They're the database equivalent of pointer-chasing in code. If you design your schema such that you need a recursive CTE to query it, be prepared for bad performance unless your CTE only ever does a handful of iterations over a handful of rows.

I like paths for representing hierarchy, but closure tables can also be a good idea, depending on what you're modelling and how you query it.

[ Parent | on HN ]

Re:Hierarchical Structures in PostgreSQL (2020) by zozbot234 on Saturday June 26, 2021 @03:18AM (#27639864)

> They're the database equivalent of pointer-chasing in code.

That's the general case, but more specific CTE queries can be optimized, e.g. by adding database indexes. Recent versions of Postgres have greatly improved wrt. not making CTE's overly inefficient.

[ Parent | on HN ]

Re:Hierarchical Structures in PostgreSQL (2020) by barrkel on Saturday June 26, 2021 @05:41PM (#27646163)

I said recursive CTEs. CTEs being an optimization barrier is a different issue - and often desirable with Postgres with its lack of optimization hints. Hence with not / materialized etc.

[ Parent | on HN ]