Re: Correction of RowMark Removal During Sel-Join Elimination
От | Andrei Lepikhov |
---|---|
Тема | Re: Correction of RowMark Removal During Sel-Join Elimination |
Дата | |
Msg-id | 4901f7de-c883-4af3-a3f0-345ba0e27edf@gmail.com обсуждение исходный текст |
Ответ на | Re: Correction of RowMark Removal During Sel-Join Elimination (Richard Guo <guofenglinux@gmail.com>) |
Список | pgsql-hackers |
On 31/8/2025 03:03, Richard Guo wrote: > On Sun, Aug 31, 2025 at 9:50 AM Alexander Korotkov <aekorotkov@gmail.com> wrote: >> On Sun, Aug 31, 2025 at 2:51 AM Richard Guo <guofenglinux@gmail.com> wrote: >>> I think it's better to push this patch sooner rather than later, as >>> multiple people have encountered the issue in different ways. I'll go >>> ahead and push 0001 from my patch set shortly. > >> I see. You're much farther than I'm. Please, go ahead pushing this. > > Done. Hmm, is this enough? As I see, it is a typical pattern: after deserialisation by the stringToNode function, Postgres attempts to call eval_const_expressions. See, for example, RelationGetIndexExpressions. That seems strange, because who knows what the entry No.1 is and how constant evaluation over this relation influences the expression tree. Perhaps it would be beneficial to refactor all this logic? Maybe go further and, before storing any relation constraint to the system catalogue, replace varno with something like 'UNDEF_VAR (-5)'? I thought about why it was designed that way. Commit eabc714 shows that at that time, the eval_const_expressions didn't touch PlannerInfo data at all. Currently, it requires query structures in some cases, particularly in prosupport functions, which necessitates having correct relation references. -- regards, Andrei Lepikhov
В списке pgsql-hackers по дате отправления: