Re: Parallel safety docs for CTEs - Mailing list pgsql-hackers

From Kirill Reshke
Subject Re: Parallel safety docs for CTEs
Date
Msg-id CALdSSPgJmSQ4XfNqu_FJO+UoW+bt5BZmYRHNkH2ThVvGAjsiQw@mail.gmail.com
Whole thread Raw
In response to Re: Parallel safety docs for CTEs  (James Coleman <jtc331@gmail.com>)
List pgsql-hackers
On Wed, 12 Mar 2025 at 22:11, James Coleman <jtc331@gmail.com> wrote:
>
> On Tue, Nov 19, 2024 at 2:16 PM James Coleman <jtc331@gmail.com> wrote:
> >
> > Hello,
> >
> > A colleague noticed today that the docs still say that "Scans of
> > common table expressions (CTEs)" are "always parallel restricted".
> >
> > While I think that strictly remains true at the implementation level,
> > from a user's perspective I think that's not been true since the
> > change to default to trying to inline CTEs rather than defaulting to
> > materializing them.
> >
> > Attached is a patch to slightly modify the language; would be happy to
> > hear suggestions on a better way to improve this.
> >
> > Regards,
> > James Coleman
>
> I'd forgotten to make a commit fest record for this and stumbled upon
> it today. See https://commitfest.postgresql.org/patch/5650/
>
> Regards,
> James Coleman
>
>


Hi!

Looks like current .sgml docs leak description of what CTE inlining
(and CTE materialising) is, and when CTE inlining applies. We only
have regression tests on this.
So, maybe we should define CTE inlining and CTE materialising, and
only then commit this change?

--
Best regards,
Kirill Reshke



pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Changing the state of data checksums in a running cluster
Next
From: Nazir Bilal Yavuz
Date:
Subject: Re: meson vs. llvm bitcode files