| Subject | Re: Varchar padding in Firebird |
|---|---|
| Author | csswa |
| Post date | 2002-05-27T17:45:21Z |
Hi Ernesto.
I'm not sure if this feature request has been officially logged or
not. I'm keen to see it. I kinda assumed that it was just one of
the IB6.5 improvements that would automatically get slated for FB. I
see it as an important performance enhancement, particularly because
there are users who define 1000+ byte varchar fields (instead of BLOB
fields), probably not realising that these values travel the network
padded to their full length.
Is this a serious performance issue? Depends if your network is
compressing data or not. If so, the padding is probably not an issue
since it gets compressed anyway. Otherwise it could be a major
performance hit, especially across a dial-up connection which is
accessing a db with big, variable-length char/varchar fields.
Go ahead and see if this feature request is logged already:
http://sourceforge.net/tracker/?atid=109028&group_id=9028&func=browse
Select the group 'feature request' before browsing.
I doubt that we'll see this feature (and other IB6.5 new features
like metadata security, XML, query killing, etc.) for a while. The
FB development team is small (but dedicated), and sadly they don't
have the 10 million bucks per year that Borland pumps into IB. Plus
there is the priority of getting the C++ FB v2 code up 'n running.
One interim solution -- if you absolutely need to compress data
across your IB/FB network connection -- is a free
encryption/compression channeling program... name escapes me but I
think I put a link to it in the Group New Users Links table (Database
link on left).
Regards,
Andrew Ferguson
-- A little song, a little dance, a little seltzer down your pants.
I'm not sure if this feature request has been officially logged or
not. I'm keen to see it. I kinda assumed that it was just one of
the IB6.5 improvements that would automatically get slated for FB. I
see it as an important performance enhancement, particularly because
there are users who define 1000+ byte varchar fields (instead of BLOB
fields), probably not realising that these values travel the network
padded to their full length.
Is this a serious performance issue? Depends if your network is
compressing data or not. If so, the padding is probably not an issue
since it gets compressed anyway. Otherwise it could be a major
performance hit, especially across a dial-up connection which is
accessing a db with big, variable-length char/varchar fields.
Go ahead and see if this feature request is logged already:
http://sourceforge.net/tracker/?atid=109028&group_id=9028&func=browse
Select the group 'feature request' before browsing.
I doubt that we'll see this feature (and other IB6.5 new features
like metadata security, XML, query killing, etc.) for a while. The
FB development team is small (but dedicated), and sadly they don't
have the 10 million bucks per year that Borland pumps into IB. Plus
there is the priority of getting the C++ FB v2 code up 'n running.
One interim solution -- if you absolutely need to compress data
across your IB/FB network connection -- is a free
encryption/compression channeling program... name escapes me but I
think I put a link to it in the Group New Users Links table (Database
link on left).
Regards,
Andrew Ferguson
-- A little song, a little dance, a little seltzer down your pants.
--- In ib-support@y..., "Ernesto Cullen" <ecullen@c...> wrote:
> That's bad... is that feature in some 'wish list'? If not, where
can i ask
> for it?
>
> Ernesto Cullen
>
>
>
> > At 07:47 PM 25-05-02 -0300, Ernesto Cullen wrote:
> > >Hi all,
> > > does Firebird pad varchar fields with spaces, as Interbase
pre-6.5
> did?
> >
> > For storage, no. For transport, yes - the client will receive
them with
> > padding.
> >
> >