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;
....................
.....................
}
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 |