pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Andrei Lepikhov <a.lepikhov@postgrespro.ru>
To: Richard Guo <guofenglinux@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Vik Fearing <vik@postgresfriends.org>
Cc: zuming.jiang@inf.ethz.ch, pgsql-bugs@lists.postgresql.org, Alexander Korotkov <akorotkov@postgresql.org>
Subject: Re: BUG #18170: Unexpected error: no relation entry for relid 3
Date: Tue, 31 Oct 2023 12:05:35 +0700
Message-ID: <7332bc61-a9fa-464b-b5a4-4e8e0f764a64@postgrespro.ru> (raw)
In-Reply-To: <CAMbWs48FTQtO=ARgjbHqz5fYtOhVUAbdEC1PpnMsjsaRsOENeQ@mail.gmail.com>
References: <18170-f1d17bf9a0d58b24@postgresql.org>
	<4ecab120-6be3-4cf6-a2a0-249c73ae91d4@postgresfriends.org>
	<1189851.1698340331@sss.pgh.pa.us>
	<011bcae5-7840-42c7-a50c-b406189e2e78@postgrespro.ru>
	<CAPpHfdsiN0norSHfw3Ujemf=RuPzMxt5PRDiyv0vqUdwSBDtoA@mail.gmail.com>
	<721542ce-79df-469e-93e9-811fadb5bd0c@postgrespro.ru>
	<2eb87c2e-7e6f-4002-8df3-8fac3aa6a037@postgrespro.ru>
	<CAMbWs494m3AjhHry_HFCFi_SJ+6-PaeMRbx7jK39ZHmK0MVOUA@mail.gmail.com>
	<c0a5b39d-8a80-47fb-bd34-6d769f88df8f@postgrespro.ru>
	<CAPpHfduPMdLm42uwuXqM1weUKSYp=2Kf-_XU2TjZsizeZ3qoWQ@mail.gmail.com>
	<CAPpHfdv_6K_sv5sL_=9EiP7Lve81WLSdiLrc22afpmg_whyxtg@mail.gmail.com>
	<2141583.1698595016@sss.pgh.pa.us>
	<CAMbWs489RP3CFKwtWoG2m=qD5byfS_9_13yVU5wyknDTb3GToQ@mail.gmail.com>
	<fc183714-a61c-4de7-97e0-b1c376923aef@postgrespro.ru>
	<CAMbWs48FTQtO=ARgjbHqz5fYtOhVUAbdEC1PpnMsjsaRsOENeQ@mail.gmail.com>

On 30/10/2023 13:24, Richard Guo wrote:
> 
> On Mon, Oct 30, 2023 at 10:47 AM Andrei Lepikhov 
> <a.lepikhov@postgrespro.ru <mailto:a.lepikhov@postgrespro.ru>> wrote:
> 
>     On 30/10/2023 09:24, Richard Guo wrote:
>      > I also have some concerns about this patch.  It requires that
>      > root->parse remains unchanged during the whole subquery_planner() in
>      > order to work, which is an implicit constraint we did not have
>     before.
> 
>     It is not about unchanged; it is about referencing the same query at
>     the
>     parent and child query blocks. Am I missing something?
> 
> 
> Yeah, that's what I meant.  We need to ensure that root->parse
> references the same Query structure during the whole subquery_planner()
> for this patch to work, which seems hacky, and error-prone for future
> development.  If we really want to do so, at least we need to emphasize
> this point in the comment of subquery_planner().

Okay, let's go another way and try to imagine what additional 
opportunities it will give us in the future? I mean, save unchanged a 
rte->subquery tree and, simultaneously, have some transformed version in 
the subroot->parse field.
I can imagine kind of a subquery replanning procedure in the case we 
realized during higher-level query planning that the underlying subquery 
is not optimal.
Such a picture makes sense, and I can agree with your words. From this 
point of view, all links to the subquery must reference the subroot 
structures, and the patch you have proposed is the best solution. And 
the SJE feature works correctly.
If we don't imagine the picture I have drawn above, it is reasonable to 
save memory and not alter the parse tree while removing unneeded joins. 
I think, in that case, we can use the walker procedure instead of a mutator.

-- 
regards,
Andrei Lepikhov
Postgres Professional






view thread (34+ messages)  latest in thread

Message-ID: <7332bc61-a9fa-464b-b5a4-4e8e0f764a64@postgrespro.ru>
Permalink:  ../7332bc61-a9fa-464b-b5a4-4e8e0f764a64@postgrespro.ru/
Also on:    postgresql.org/message-id/7332bc61-a9fa-464b-b5a4-4e8e0f764a64@postgrespro.ru

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: a.lepikhov@postgrespro.ru, guofenglinux@gmail.com, tgl@sss.pgh.pa.us, aekorotkov@gmail.com, vik@postgresfriends.org, akorotkov@postgresql.org
  Subject: Re: BUG #18170: Unexpected error: no relation entry for relid 3
  In-Reply-To: <7332bc61-a9fa-464b-b5a4-4e8e0f764a64@postgrespro.ru>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox