On Thu, Apr 17, 2025 at 1:22 AM Tom Lane wrote:
> Now, subquery_planner does have side effects on the PlannerGlobal
> struct, but that's planner-local data, not an input to the planner.
That reminded me of one place where we currently mutate planner input:
inserting child RTEs into each subquery’
On 4/16/25 18:22, Tom Lane wrote:
Maybe we would like to have some enforced contract about what
subquery_planner can and can't touch in the outer planner level's
data, but I'm not feeling a great need for that right now.
I wouldn't say I'm entirely convinced that side effects are absent, but
mul
Andrei Lepikhov writes:
> I just want to understand how your idea will work. The query_planner
> does the job for subqueries separately. If a query is transformed in
> some way (let's say, an unnecessary join is deleted), we need to change
> references in the parse tree of another subquery, or
On 4/15/25 19:34, Tom Lane wrote:
Andrei Lepikhov writes:
But what is the way you are proposing here? Do you mean that one more
entity will be explicitly introduced: a transformed parse tree?
No, I wasn't thinking of adding new concepts, just saying that the
inputs to certain operations need
On Sat, Apr 5, 2025 at 7:31 PM Andres Freund wrote:
> Hi,
>
> On 2025-04-05 12:46:37 -0400, Tom Lane wrote:
> > 1. Invent a way to make a particular memory context read-only
> > after putting some data into it.
> >
> > 2. In debug builds, after we've built a tree that should be considered
> > rea
Andrei Lepikhov writes:
> But what is the way you are proposing here? Do you mean that one more
> entity will be explicitly introduced: a transformed parse tree?
No, I wasn't thinking of adding new concepts, just saying that the
inputs to certain operations need to be treated as read-only.
What
Richard Guo writes:
> On Sun, Apr 6, 2025 at 1:46 AM Tom Lane wrote:
>> Years ago we fixed the executor to treat its input Plan trees as
>> read-only. It seems like we really ought to do the same for these
>> upstream subsystems. Surely, whatever benefit we get from changing
>> Node contents in
On 4/5/25 18:46, Tom Lane wrote:
I'm not planning to pursue this idea Right Now, but it seems like
something that could happen for v19 or so. In the meantime I wanted
to get the ideas down on electrons.
Thoughts?
I generally like the idea because, for now, I need to be sure that no
one touched
On Sun, Apr 6, 2025 at 1:46 AM Tom Lane wrote:
> The parser, rewriter, and planner all have a bad habit of scribbling
> on their input parsetrees. At this point I've lost count of how many
> bugs that's caused (but e33f2335a and 0f43083d1 are the two latest
> examples), and of how many places the
Hi,
On 2025-04-05 12:46:37 -0400, Tom Lane wrote:
> 1. Invent a way to make a particular memory context read-only
> after putting some data into it.
>
> 2. In debug builds, after we've built a tree that should be considered
> read-only, copy it into such a context and make it read-only. Or
> per
The parser, rewriter, and planner all have a bad habit of scribbling
on their input parsetrees. At this point I've lost count of how many
bugs that's caused (but e33f2335a and 0f43083d1 are the two latest
examples), and of how many places there are that are brute-forcing a
solution to the problem
11 matches
Mail list logo
