Re: [HACKERS] 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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

> > 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(at)debis(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

> > > 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.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck(at)debis(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

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(at)pacifier(dot)com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

wieck(at)debis(dot)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