Re: Explain plan changes - IN CLAUSE ( Passing direct values Vs INNER Query ) - Mailing list pgsql-performance

From Tom Lane
Subject Re: Explain plan changes - IN CLAUSE ( Passing direct values Vs INNER Query )
Date
Msg-id 32488.1588886768@sss.pgh.pa.us
Whole thread Raw
In response to Re: Explain plan changes - IN CLAUSE ( Passing direct values Vs INNERQuery )  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-performance
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Thu, May 7, 2020 at 10:49 AM Amarendra Konda <amar.vijaya@gmail.com>
> wrote:
>> Can you please explain, why it is getting more columns in output, even
>> though we have asked for only one column ?
>> * Output: pa.process_activity_id, pa.process_activity_type, pa.voice_url,
>> pa.process_activity_user_id, pa.app_id, pa.process_instance_id, pa.alias,
>> pa.read_by_user, pa.source, pa.label_category_id, pa.label_id,
>> pa.csat_response_id, m.process_activity_fragments, pa.created, pa.updated,
>> pa.rule_id, pa.marketing_reply_id, pa.delivered_at, pa.reply_fragments,
>> pa.status_fragment, pa.internal_meta, pa.interaction_id,
>> pa.do_not_translate, pa.should_translate, pa.in_reply_to*

> Not knowing the source code in this area at all...

> I'm pretty sure its because it doesn't matter.

It's actually intentional, to save a projection step within that plan
node.  We'll discard the extra columns once it matters, at some higher
plan level.

(There have been some debates on -hackers about whether this optimization
is still worth anything, given all the executor improvements that have
been made since it went in.  But it was clearly a win at the time.)

            regards, tom lane



pgsql-performance by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: Explain plan changes - IN CLAUSE ( Passing direct values Vs INNERQuery )
Next
From: "David G. Johnston"
Date:
Subject: Re: Explain plan changes - IN CLAUSE ( Passing direct values Vs INNERQuery )