| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Amit Langote <amitlangote09(at)gmail(dot)com> |
| Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: generic plans and "initial" pruning |
| Date: | 2022-04-01 03:45:45 |
| Message-ID: | 922566.1648784745@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Amit Langote <amitlangote09(at)gmail(dot)com> writes:
> On Fri, Apr 1, 2022 at 10:32 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>> 1. You've changed the signature of various functions by adding
>> ExecLockRelsInfo *execlockrelsinfo. I'm wondering why you didn't just
>> put the ExecLockRelsInfo as a new field in PlannedStmt?
> I'm worried about that churn myself and did consider this idea, though
> I couldn't shake the feeling that it's maybe wrong to put something in
> PlannedStmt that the planner itself doesn't produce.
PlannedStmt is part of the plan tree, which MUST be read-only to
the executor. This is not negotiable. However, there's other
places that this data could be put, such as QueryDesc.
Or for that matter, couldn't the data structure be created by
the planner? (It looks like David is proposing exactly that
further down.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Noah Misch | 2022-04-01 03:47:28 | Re: Unit tests for SLRU |
| Previous Message | Noah Misch | 2022-04-01 03:42:41 | Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set |