Horton

Thread

  1. A further thought on rule string size

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-02-27T22:39:07Z

    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

  2. Re: [HACKERS] A further thought on rule string size

    Bruce Momjian <pgman@candle.pha.pa.us> — 2000-02-27T23:49:29Z

    > 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, Pennsylvania 19026

  3. Re: [HACKERS] A further thought on rule string size

    Jan Wieck <wieck@debis.com> — 2000-02-28T07:22:06Z

    > > 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) #

  4. Re: [HACKERS] A further thought on rule string size

    Bruce Momjian <pgman@candle.pha.pa.us> — 2000-02-28T08:28:10Z

    > > > 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, Pennsylvania 19026

  5. Re: [HACKERS] A further thought on rule string size

    Jan Wieck <wieck@debis.com> — 2000-02-28T08:28:29Z

    > > > 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@debis.com (Jan Wieck) #

  6. Re: [HACKERS] A further thought on rule string size

    Bruce Momjian <pgman@candle.pha.pa.us> — 2000-02-28T09:10:59Z

    > > > > 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, Pennsylvania 19026

  7. Re: [HACKERS] A further thought on rule string size

    Don Baccus <dhogaza@pacifier.com> — 2000-02-28T14:21:41Z

    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 Service and other goodies at
  http://donb.photo.net.

  8. Re: [HACKERS] A further thought on rule string size

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-02-28T14:40:01Z

    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