Thread: A further thought on rule string size
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
> 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? If you could keep the labels just for EXPLAIN, go for it. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> > 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? > > If you could keep the labels just for EXPLAIN, go for it. Not right now, put it onto TODO for after 7.0. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #========================================= wieck@debis.com (Jan Wieck) #
> > > 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? > > > > If you could keep the labels just for EXPLAIN, go for it. > > Not right now, put it onto TODO for after 7.0. But we just required initdb for lztext. If we need another initdb later, maybe we should do it? -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> > > If you could keep the labels just for EXPLAIN, go for it. > > > > Not right now, put it onto TODO for after 7.0. > > But we just required initdb for lztext. If we need another initdb > later, maybe we should do it? LZTEXT was a fairly limited change, tested out before and just reapplied. This time you ask for mucking with thefamily of node-print and -read functions. Even if it's a limited area of code affected, I don't feel comfortabledoing it now. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #========================================= wieck@debis.com (Jan Wieck) #
> > > > If you could keep the labels just for EXPLAIN, go for it. > > > > > > Not right now, put it onto TODO for after 7.0. > > > > But we just required initdb for lztext. If we need another initdb > > later, maybe we should do it? > > LZTEXT was a fairly limited change, tested out before and > just reapplied. This time you ask for mucking with the family > of node-print and -read functions. Even if it's a limited > area of code affected, I don't feel comfortable doing it now. OK. Added to TODO. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
At 09:28 AM 2/28/00 +0100, Jan Wieck wrote: >> > > If you could keep the labels just for EXPLAIN, go for it. >> > >> > Not right now, put it onto TODO for after 7.0. >> >> But we just required initdb for lztext. If we need another initdb >> later, maybe we should do it? > > LZTEXT was a fairly limited change, tested out before and > just reapplied. This time you ask for mucking with the family > of node-print and -read functions. Even if it's a limited > area of code affected, I don't feel comfortable doing it now. And lztext compression of the rule strings is such a big win that I suspect folks upgrading from 6.5 to 7.0 won't have to worry about having their views blow up in their face. So the "mini-crisis" is solved, folks will be able to upgrade smoothly, and in practice will be able to build views on tables with many more columns. Removing the additional verbosity from the rule strings is also a good idea, but doesn't feel like a critical-path thing to me. So I think Jan's right, it can wait. - Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Serviceand other goodies at http://donb.photo.net.
wieck@debis.com (Jan Wieck) writes:
>> But we just required initdb for lztext. If we need another initdb
>> later, maybe we should do it?
That was what I was thinking, too. But...
> LZTEXT was a fairly limited change, tested out before and
> just reapplied. This time you ask for mucking with the family
> of node-print and -read functions. Even if it's a limited
> area of code affected, I don't feel comfortable doing it now.
Yeah, Jan is probably right --- too much risk of breaking something
and not noticing till after release. 7.0 will already allow longer
rules than 6.5 because of lztext, so it's not critical to do this now.
Let's wait.
regards, tom lane