Re: [HACKERS] type coerce problem with lztext

Don Baccus <dhogaza@pacifier.com> writes:
> This is the "explosion" in length due to the column aliases now
> being inserted into the rule, apparently.
> lztext is doing a GREAT job of sweeping this problem under the rug,
> so to speak, but it's still there...

Actually, as far as I can tell 7.0 should be only marginally worse than
prior releases in terms of verbosity of the rule parsetree string.
As a check I did

create table foo (f1 int, f2 char(10), f3 text);
create view foov as select * from foo;
select ev_action from pg_rewrite where rulename = '_RETfoov';

and got (linebreaks inserted for readability)

({ QUERY :command 1 :utility <> :resultRelation 0 :into <> :isPortal
false :isBinary false :isTemp false :unionall false :distinctClause <>
:sortClause <>:rtable (
{ RTE :relname foov :ref { ATTR :relname *CURRENT*:attrs ( "f1" "f2" "f3" )}:relid 148363 :inh false :inFromCl false
:inJoinSetfalse :skipAcl false}
 
{ RTE :relname foov :ref { ATTR :relname *NEW*:attrs ( "f1" "f2" "f3" )}:relid 148363 :inh false :inFromCl false
:inJoinSetfalse :skipAcl false}
 
{ RTE :relname foo :ref { ATTR :relname foo:attrs ( "f1" "f2" "f3" )}:relid 148352 :inh false :inFromCl true :inJoinSet
true:skipAcl false}):targetlist (
 
{ TARGETENTRY :resdom { RESDOM :resno 1 :restype 23 :restypmod -1
:resname f1 :reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk false }
:expr { VAR :varno 3 :varattno 1 :vartype 23 :vartypmod -1
:varlevelsup 0 :varnoold 3 :varoattno 1}}
{ TARGETENTRY :resdom { RESDOM :resno 2 :restype 1042 :restypmod 14
:resname f2 :reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk false }
:expr { VAR :varno 3 :varattno 2 :vartype 1042 :vartypmod 14
:varlevelsup 0 :varnoold 3 :varoattno 2}}
{ TARGETENTRY :resdom { RESDOM :resno 3 :restype 25 :restypmod -1
:resname f3 :reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk false }
:expr { VAR :varno 3 :varattno 3 :vartype 25 :vartypmod -1
:varlevelsup 0 :varnoold 3 :varoattno 3}}):qual <> :groupClause <> :havingQual <> :hasAggs false :hasSubLinks
false :unionClause <> :intersectClause <> :limitOffset <> :limitCount <>
:rowMark <>})

The thrice-repeated list of attribute names in the rtable entries is
new with Thomas' latest changes, and I'd like to see it go away again,
but even so it's not very long compared to the targetlist entries.

The inJoinSet fields in rtable entries are new, and ressortgroupref
used to be called resgroupref which is costing us 4 more bytes per
targetlist item ;-).  But otherwise it's three occurrences of the
field name added onto an existing cost of about 230 bytes per target
entry.  This is not an "explosion".

In fact, if I do
select length(ev_action) from pg_rewrite where rulename = '_RETfoov';
I get 1507 in current sources and 1318 in 6.5.3, or about 15% growth.

My guess is that Don's problems are stemming from rules that reference
tables that have many more columns than are being output.  Citations
of the otherwise-unreferenced columns in the rtable could add a lot of
bulk that wasn't there before.  But it doesn't look to me like the size
of a simple "SELECT *" rule string has grown all that much.
        regards, tom lane