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
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 |