Re: Parallel safety docs for CTEs

From: Kirill Reshke <reshkekirill(at)gmail(dot)com>
To: James Coleman <jtc331(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parallel safety docs for CTEs
Date: 2025-03-13 10:01:46
Message-ID: CALdSSPgJmSQ4XfNqu_FJO+UoW+bt5BZmYRHNkH2ThVvGAjsiQw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 12 Mar 2025 at 22:11, James Coleman <jtc331(at)gmail(dot)com> wrote:
>
> On Tue, Nov 19, 2024 at 2:16 PM James Coleman <jtc331(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nazir Bilal Yavuz 2025-03-13 10:11:44 Re: meson vs. llvm bitcode files
Previous Message Daniel Gustafsson 2025-03-13 09:54:28 Re: Changing the state of data checksums in a running cluster