Re: BUG #15820: Commuting two column make a SubqueryScan node to appear in the plan

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: luis(dot)carril(at)swarm64(dot)com
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #15820: Commuting two column make a SubqueryScan node to appear in the plan
Date: 2019-05-27 13:09:34
Message-ID: 65155.1558962574@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> switching the order of two columns make a SubqueryScan node to appear in
> the plan. It seems completely trivial as the cost is not modified, should it
> also be removed in the second case?

No. The SubqueryScan can only be optimized away if it makes no changes
in the result tuple.

Conceivably, with sufficiently complicated hacking in setrefs.c,
simple cases like column reordering could be handled there. But
I'm doubtful that it's worth the added cycles & risk of bugs.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2019-05-27 16:11:37 BUG #15821: Parallel Workers with functions and auto_explain: ERROR: could not find key 3 in shm TOC
Previous Message PG Bug reporting form 2019-05-27 12:54:27 BUG #15820: Commuting two column make a SubqueryScan node to appear in the plan