Thread: AW: [HACKERS] varchar() vs char16 performance

I had thought that char2-16 add _no_ functionality over the char() and
varchar() types; Tatsuo points out at least one capability which they
have. Are there any others?

They give and take a char * pointer to a C function like
create function upper(char16)
returning char16 as '/u/my/upper.so' language 'sql';
whereas char() gives a varlena pointer.

Andreas

> I had thought that char2-16 add _no_ functionality over the char() and
> varchar() types; Tatsuo points out at least one capability which they
> have. Are there any others?
>
> They give and take a char * pointer to a C function like
> create function upper(char16)
> returning char16 as '/u/my/upper.so' language 'sql';
> whereas char() gives a varlena pointer.

I don't really see this as a big deal since, for example, only 16 bytes
are allocated for a char16, so it is not guaranteed to be zero delimited
and you have to make a working copy to use libc functions anyway. Also,
that is really an implementation detail or annoyance rather than a
user-visible feature.

With the macros that are provided for the varlena structure
manipulations, things are pretty convenient. Are there more macros which
could be helpful here??

                       - Tom

> I had thought that char2-16 add _no_ functionality over the char() and
> varchar() types; Tatsuo points out at least one capability which they
> have. Are there any others?
>
> They give and take a char * pointer to a C function like
> create function upper(char16)
> returning char16 as '/u/my/upper.so' language 'sql';
> whereas char() gives a varlena pointer.
>

The char[248] types rip out just fine.

But that char16 is a whole new beast.  It's tentacles are everywhere...

From comments in various files, the char16 was the original name type
and was then replaced with 'name'.  But there are still a few places
of inconsistency in the code, namely (*bad pun*) in the cache code.

There is this eqproc array in catcache.c that is a hack that has to
match the oids of the types from oid 16 to 30, except that F_CHAR16EQ
is still where F_NAMEEQ should be.  Tried renaming it last night, but
initdb would blowup the first insert, so there is some other effect in
the caching code.

Still other incomplete conversions.  In pg_proc.h the arg types for
char16eq, lt, le, gt, ge & ne are names (oid 19) when they should be
char16 (oid 20)!  But char16eq is correctly defined to take char16
in pg_operator.h.

I'll work on this some more tonite.

darrenk

>
> > I had thought that char2-16 add _no_ functionality over the char() and
> > varchar() types; Tatsuo points out at least one capability which they
> > have. Are there any others?
> >
> > They give and take a char * pointer to a C function like
> > create function upper(char16)
> > returning char16 as '/u/my/upper.so' language 'sql';
> > whereas char() gives a varlena pointer.
> >
>
> The char[248] types rip out just fine.
>
> But that char16 is a whole new beast.  It's tentacles are everywhere...
>
> >From comments in various files, the char16 was the original name type
> and was then replaced with 'name'.  But there are still a few places
> of inconsistency in the code, namely (*bad pun*) in the cache code.

Yes, you are correct.  That was the original name length.

I thought I fixed all the cache name16 references before 6.3.  That is
why we can now have index names over 16 characters.  Can you confirm
this is still a problem in 6.3.

>
> There is this eqproc array in catcache.c that is a hack that has to
> match the oids of the types from oid 16 to 30, except that F_CHAR16EQ
> is still where F_NAMEEQ should be.  Tried renaming it last night, but
> initdb would blowup the first insert, so there is some other effect in
> the caching code.
>
> Still other incomplete conversions.  In pg_proc.h the arg types for
> char16eq, lt, le, gt, ge & ne are names (oid 19) when they should be
> char16 (oid 20)!  But char16eq is correctly defined to take char16
> in pg_operator.h.
>
> I'll work on this some more tonite.

Great.

--
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

> I don't really see this as a big deal since, for example, only 16 bytes
> are allocated for a char16, so it is not guaranteed to be zero delimited
> and you have to make a working copy to use libc functions anyway. Also,
> that is really an implementation detail or annoyance rather than a
> user-visible feature.

Agreed.

> With the macros that are provided for the varlena structure
> manipulations, things are pretty convenient. Are there more macros which
> could be helpful here??

From postgres.h:

    #define VARSIZE(PTR)    (((struct varlena *)(PTR))->vl_len)
    #define VARDATA(PTR)    (((struct varlena *)(PTR))->vl_dat)
    #define VARHDRSZ        sizeof(int32)

I have gone throught the code before 6.3, and changed many hard-coded
4's to use these macros.
--
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)