-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow non-recursive CTEs to avoid optimization fence #31
Comments
After reviewing the documentation I am unable to determine if the
The WITH RECURSIVE s(m) AS (
SELECT 0 -- is this considered recursive?
), t(n) AS (
SELECT 1
UNION ALL
SELECT n+1 FROM t -- this certainly is recursive
)
SELECT m, n FROM s, t LIMIT 10; It seems reasonable to interpret the phrase " The SQLite documentation is more explicit, although there
|
In Postgres 12 the default behavior of CTEs changed. They're no longer materialized if they are non-recursive, side-effect free and only appear once in the query: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=608b167f9f9c4553c35bb1ec0eab9ddae643989b
django-cte makes all CTEs recursive: https://github.com/dimagi/django-cte/blob/master/django_cte/query.py#L85
It would be nice to have the option to have non-recursive CTEs to avoid them being optimization fences.
The text was updated successfully, but these errors were encountered: