pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Andrei Lepikhov <a.lepikhov@postgrespro.ru>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Richard Guo <guofenglinux@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
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: Sat, 28 Oct 2023 18:00:55 +0700
Message-ID: <b6fce1cd-3608-4188-b008-f90320e0f92d@postgrespro.ru> (raw)
In-Reply-To: <CAPpHfduPMdLm42uwuXqM1weUKSYp=2Kf-_XU2TjZsizeZ3qoWQ@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>

On 28/10/2023 17:10, Alexander Korotkov wrote:
>>
>> It is a solution. But does it mask the real problem? In my mind, we copy
>> node trees to use somewhere else or probe a conjecture. Here, we have
>> two different representations of the same subquery. Keeping aside the
>> memory consumption issue, is it correct?
>> Make sense to apply both options: switch the groups estimation to
>> subroot targetList and keep one version of a subquery.
>> In attachment - second (combined) version of the change. Here I added
>> assertions to check identity of root->parse and incoming query tree.
> 
> Andrei, did you read the comment just before the groups estimation as
> pointed by Tom [1]?

Yes, and I am a bit confused. We use here subroot->parse->targetList. 
The processed_tlist, where we can find the "Varno 0" value, is based on 
it, but it is different. As I see, forming processed_tlist, we make a 
new node and don't change the original targetList. Am I wrong?

> * XXX you don't really want to know about this: we do the estimation
> * using the subquery's original targetlist expressions, not the
> * subroot->processed_tlist which might seem more appropriate. The
> * reason is that if the subquery is itself a setop, it may return a
> * processed_tlist containing "varno 0" Vars generated by
> * generate_append_tlist, and those would confuse estimate_num_groups
> * mightily. We ought to get rid of the "varno 0" hack, but that
> * requires a redesign of the parsetree representation of setops, so
> * that there can be an RTE corresponding to each setop's output.
> 
> As I understand, it requires much more work to correctly switch the
> groups estimation to subroot targetList.

"Varno 0" is quite an irritating problem, which has beaten me a lot 
before, during the development of the GROUP-BY optimization feature and 
not only. I'd be glad to redesign this part of the planner. But I didn't 
find an easy way to implement that yet.

-- 
regards,
Andrei Lepikhov
Postgres Professional






view thread (34+ messages)  latest in thread

Message-ID: <b6fce1cd-3608-4188-b008-f90320e0f92d@postgrespro.ru>
Permalink:  ../b6fce1cd-3608-4188-b008-f90320e0f92d@postgrespro.ru/
Also on:    postgresql.org/message-id/b6fce1cd-3608-4188-b008-f90320e0f92d@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, aekorotkov@gmail.com, guofenglinux@gmail.com, tgl@sss.pgh.pa.us, vik@postgresfriends.org, akorotkov@postgresql.org
  Subject: Re: BUG #18170: Unexpected error: no relation entry for relid 3
  In-Reply-To: <b6fce1cd-3608-4188-b008-f90320e0f92d@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