| Subject | Re: [Firebird-Architect] Re: The Wolf on Firebird 3 |
|---|---|
| Author | Olivier Mascia |
| Post date | 2005-11-16T19:10:26Z |
Hi Roman,
Le 16 nov. 05 à 19:31, Roman Rokytskyy a écrit :
that talk to Firebird. The point was to say that the saving of bytes
at the database system level, can be lost in other OS interactions by
the end-user program which at first was happy to have saved bytes
from the DB.
Honestly, in my own very personal opinion, assuming no kind of
compression (so considering a worst-case scenario only), the whole
things comes down to this : do we accept the risk of multiplying the
storage requirements of strings inside a DB by 2x, 3x, 4x times
(extreme cases) ? I do. That may be just me. No matter. I'm just
exposing my views. What will advent then is out of my control anyway
(and that's certainly good that way :) ).
it is, but let me doubt based on issues encountered trying to use it
- okay last year and not on fb2), yes it would be some indicator. Not
an exact one of course, because such a utf8-ization of the internals
and storage would certainly receive a great deal of attention to
architecture and implementation details. (I have fear that the
current UNICODE_FSS implementation uses 3 bytes for each char, needed
or not. Also when defining columns, the length you have to give is a
kind of byte count, so you have to declare your size * 3, if I
remember well. That is obviously not how it should work. That's why I
fear the comparison would be probably unfair based on FB1 or FB2. But
again that may be an indicator. )
--
Olivier
Le 16 nov. 05 à 19:31, Roman Rokytskyy a écrit :
>> Come on. Each and every system call your beloved program does to theI know that. I was of course refering to end-user programs, those
>> Win32 API on Windows 2000, Windows XP, Windows Server 2003, and
>> every other newer version to come for a while spend its time
>> converting your one-byte chars to two or four bytes per char. Each
>> in-parameter gets widened and then each out-parameters gets
>> shortened on the return.
>
> Well... AFAIK, Firebird does not use OS calls for its string
> operations.
that talk to Firebird. The point was to say that the saving of bytes
at the database system level, can be lost in other OS interactions by
the end-user program which at first was happy to have saved bytes
from the DB.
Honestly, in my own very personal opinion, assuming no kind of
compression (so considering a worst-case scenario only), the whole
things comes down to this : do we accept the risk of multiplying the
storage requirements of strings inside a DB by 2x, 3x, 4x times
(extreme cases) ? I do. That may be just me. No matter. I'm just
exposing my views. What will advent then is out of my control anyway
(and that's certainly good that way :) ).
> Would comparisson of WIN1251 database and UNICODE_FSS one with theIf the thing named UNICODE_FSS is correctly implemented (which maybe
> same data be a fair test of the performance on Firebird 2.0?
it is, but let me doubt based on issues encountered trying to use it
- okay last year and not on fb2), yes it would be some indicator. Not
an exact one of course, because such a utf8-ization of the internals
and storage would certainly receive a great deal of attention to
architecture and implementation details. (I have fear that the
current UNICODE_FSS implementation uses 3 bytes for each char, needed
or not. Also when defining columns, the length you have to give is a
kind of byte count, so you have to declare your size * 3, if I
remember well. That is obviously not how it should work. That's why I
fear the comparison would be probably unfair based on FB1 or FB2. But
again that may be an indicator. )
--
Olivier