A further thought on rule string size

Поиск
Список
Период
Сортировка
От Tom Lane
Тема A further thought on rule string size
Дата
Msg-id 17072.951691147@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: [HACKERS] A further thought on rule string size  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
Looking at the example I just cited, it's hard to avoid noticing how
much space is being used on purely-decorative field labels.
For example,

{ 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}}

doesn't really contain any information that's not in

{ TARGETENTRY { RESDOM 1 23 -1 f1 0 0 0 false } { VAR 3 1 23 -1 0 3 1}}

which takes a third as much space.  Now I think I'd want to stick with
the more-verbose form for EXPLAIN output and debugging displays, but
I wonder if it isn't worth while to strip the labels from stored rule
strings.

Removing the labels would actually save code in readfuncs.c, which
wouldn't have to skip over them.  In outfuncs.c, we could either
have every node-writing subroutine know about two output modes, or
make a post-pass that strips anything that looks like a field label.
The latter would be less maintenance work in the long run.

Comments?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Don Baccus
Дата:
Сообщение: Re: [HACKERS] type coerce problem with lztext
Следующее
От: Keith Parks
Дата:
Сообщение: Rogue line in regression resultmap file.