| From: | Amit Langote <amitlangote09(at)gmail(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Daniel Gustafsson <daniel(at)yesql(dot)se>, David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Thom Brown <thom(at)linux(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: generic plans and "initial" pruning |
| Date: | 2024-09-19 12:10:04 |
| Message-ID: | CA+HiwqFGz2uShfU=qtack9gii6Kzyjv1V66tJJBYBN8Acb4uTA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Sep 19, 2024 at 5:39 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> For
> ResultRelInfos, I took the approach of memsetting them to 0 for pruned
> result relations and adding checks at multiple sites to ensure the
> ResultRelInfo being handled is valid.
After some reflection, I realized that nobody would think that that
approach is very robust. In the attached, I’ve modified
ExecInitModifyTable() to allocate ResultRelInfos only for unpruned
relations, instead of allocating for all in
ModifyTable.resultRelations and setting pruned ones to 0. This
approach feels more robust.
--
Thanks, Amit Langote
| Attachment | Content-Type | Size |
|---|---|---|
| v55-0001-Move-PartitionPruneInfo-out-of-plan-nodes-into-P.patch | application/octet-stream | 19.9 KB |
| v55-0003-Initialize-PartitionPruneContext-for-exec-prunin.patch | application/octet-stream | 11.8 KB |
| v55-0002-Perform-runtime-initial-pruning-outside-ExecInit.patch | application/octet-stream | 17.3 KB |
| v55-0004-Defer-locking-of-runtime-prunable-relations-to-e.patch | application/octet-stream | 45.1 KB |
| v55-0005-Handle-CachedPlan-invalidation-in-the-executor.patch | application/octet-stream | 58.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | vignesh C | 2024-09-19 12:13:09 | Re: Conflict Detection and Resolution |
| Previous Message | Ashutosh Bapat | 2024-09-19 11:12:14 | Re: Memory consumed by paths during partitionwise join planning |