Is it possible and worthy to optimize scanRTEForColumn()?

From: Rui Hai Jiang <ruihaijiang(at)msn(dot)com>
To: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Is it possible and worthy to optimize scanRTEForColumn()?
Date: 2017-12-08 06:39:26
Message-ID: SG2PR02MB1102919F35405ABC8AFD7FFCA0300@SG2PR02MB1102.apcprd02.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello,

When I run a select query, e.g. select id from t, all columns in table "t" are checked to see if a column named "id" exists or not, and a Var is created for "id" if the column does exist.

Function scanRTEForColumn() does this job.

But I see in scanRTEForColumn(), the loop does not stop when a match is found, it continues to compare all other columns. And this will waste lots of computing.

I guess there may be some reasons for this. But I don't know yet. I just wonder if it is possible and worthy to optimize this. And please note, "select *" does not call this function.

Node *
scanRTEForColumn(ParseState *pstate, RangeTblEntry *rte, char *colname,
int location, int fuzzy_rte_penalty,
FuzzyAttrMatchState *fuzzystate)
{
foreach(c, rte->eref->colnames)
{
const char *attcolname = strVal(lfirst(c));
attnum++;
if (strcmp(attcolname, colname) == 0)
{
if (result)
ereport(ERROR,
(errcode(ERRCODE_AMBIGUOUS_COLUMN),
errmsg("column reference \"%s\" is ambiguous",
colname),
parser_errposition(pstate, location)));
var = make_var(pstate, rte, attnum, location);
/* Require read access to the column */
markVarForSelectPriv(pstate, var, rte);
result = (Node *) var;
}

/* Updating fuzzy match state, if provided. */
if (fuzzystate != NULL)
updateFuzzyAttrMatchState(fuzzy_rte_penalty, fuzzystate,
rte, attcolname, colname, attnum);
}

/*
* If we have a unique match, return it. Note that this allows a user
* alias to override a system column name (such as OID) without error.
*/
if (result)
return result;

....................
.....................
}

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Kretschmer 2017-12-08 07:20:40 Re: Table with large number of int columns, very slow COPY FROM
Previous Message Bruce Momjian 2017-12-08 06:24:21 Re: Speeding up pg_upgrade