From: | Andrei Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru> |
---|---|
To: | Richard Guo <guofenglinux(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Oversight in reparameterize_path_by_child leading to executor crash |
Date: | 2023-10-13 10:18:19 |
Message-ID: | 4f06fbf2-9892-4e66-b840-dee37536916b@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 23/8/2023 12:37, Richard Guo wrote:
> To fix it we may need to modify RelOptInfos for Path, BitmapHeapPath,
> ForeignPath and CustomPath, and modify IndexOptInfos for IndexPath. It
> seems that that is not easily done without postponing reparameterization
> of paths until createplan.c.
>
> Attached is a patch which is v5 + fix for this new issue.
Having looked into the patch for a while, I couldn't answer to myself
for some stupid questions:
1. If we postpone parameterization until the plan creation, why do we
still copy the path node in the FLAT_COPY_PATH macros? Do we really need it?
2. I see big switches on path nodes. May it be time to create a
path_walker function? I recall some thread where such a suggestion was
declined, but I don't remember why.
3. Clause changing is postponed. Why does it not influence the
calc_joinrel_size_estimate? We will use statistics on the parent table
here. Am I wrong?
--
regards,
Andrey Lepikhov
Postgres Professional
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2023-10-13 10:44:30 | Re: pg_upgrade's interaction with pg_resetwal seems confusing |
Previous Message | Amit Kapila | 2023-10-13 09:50:30 | Re: pg_logical_emit_message() misses a XLogFlush() |