Re: [HACKERS] type coerce problem with lztext - Mailing list pgsql-hackers
From | Tom Lane |
---|---|
Subject | Re: [HACKERS] type coerce problem with lztext |
Date | |
Msg-id | 16921.951688922@sss.pgh.pa.us Whole thread Raw |
In response to | Re: [HACKERS] type coerce problem with lztext (Don Baccus <dhogaza@pacifier.com>) |
Responses |
Re: [HACKERS] type coerce problem with lztext
|
List | pgsql-hackers |
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
pgsql-hackers by date: