Re: OCTET_LENGTH is wrong

> Peter Eisentraut <peter_e@gmx.net> writes:
> > I noticed OCTET_LENGTH will return the size of the data after TOAST may
> > have compressed it.  While this could be useful information, this
> > behaviour has no basis in the SQL standard and it's not what is
> > documented.  Moreover, it eliminates the standard useful behaviour of
> > OCTET_LENGTH, which is to show the length in bytes of a multibyte string.
> 
> I wondered about that too, the first time I noticed it.  On the other
> hand, knowing the compressed length is kinda useful too, at least for
> hacking and DBA purposes.  (One might also like to know whether a value
> has been moved out of line, which is not currently determinable.)
> 
> I don't want to force an initdb at this stage, at least not without
> compelling reason, so adding more functions right now is not feasible.
> Maybe a TODO item for next time.
> 
> That leaves us with the question whether to change OCTET_LENGTH now
> or leave it for later.  Anyone?

I am unconcerned about showing people the actual toasted length.  Seems
we should get octet_length() computed on the un-TOASTED length, if we
can.

> BTW, I noticed that textlength() is absolutely unreasonably slow when
> MULTIBYTE is enabled --- yesterday I was trying to profile TOAST
> overhead, and soon discovered that what I was looking at was nothing
> but pg_mblen() calls.  It really needs a short-circuit path for
> single-byte encodings.

Added to TODO:
* Optimize textlength(), etc. for single-byte encodings

--  Bruce Momjian                        |  http://candle.pha.pa.us 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