| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: WIP: Faster Expression Processing v4 |
| Date: | 2017-03-25 03:01:19 |
| Message-ID: | 13918.1490410879@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
btw ... I just got around to looking at a code coverage report for this
patched version, and that reminded me of something I'd already suspected:
EEOP_INNER_SYSVAR and EEOP_OUTER_SYSVAR seem to be dead code. That's
unsurprising, because we never try to access a tuple's system columns
above the scan level. If a query asks for system columns, those get
passed up to upper query levels as ordinary user-side columns.
We could keep the execution support for those opcodes, or we could rip it
out and throw an error in execExpr.c if one would need to be generated.
I'm a little inclined to the latter, because it seems like the plan is
to grow more support for every opcode in the future. We don't need to
be adding support for unreachable opcodes.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2017-03-25 03:46:15 | pgsql: Add COMMENT and SECURITY LABEL support for publications and subs |
| Previous Message | Thomas Munro | 2017-03-25 02:40:51 | Re: dsm.c API tweak |