On Mon, 23 Feb 2015 10:54:56 +0300, Dmitry Yemanov
wrote:
> 22.02.2015 15:10, Mark Rotteveel wrote:
>
>> I am reimplementing the event handling in Jaybird, and the current
(old)
>> implementation on the asynchronous port (event connection) processes
the
>> operations:
>>
>> op_dummy, op_exit, op_
22.02.2015 20:11, Adriano dos Santos Fernandes wrote:
> A solution must be to pass a parameter to destroy methods specifying if
> they should release or not the object.
Must be ? I don't think so. I'm not ready to point to correct solution
right now, but additional parameter is not a solution,
On 23/02/2015 07:36, Vlad Khorsun wrote:
> 22.02.2015 20:11, Adriano dos Santos Fernandes wrote:
>
>> A solution must be to pass a parameter to destroy methods specifying if
>> they should release or not the object.
>Must be ? I don't think so. I'm not ready to point to correct solution
> right
Hi,
for FB3 I will recomend more effective algoritm than hacking this
current one.
If you are interested, I can specify.
I was made another test with release build windows 64 bit and results:
DB size decrese from 90GB -> 60 GB.
Some select count(*) from table like this one:
Create Table Produ
I'm been using a self-describing value encoding for a decade and a half.
It's denser and cheaper to compress and decompress than the existing run
length encoding, though I'm not sure that compressing version delta would
be a lot of fun, but probably some clever fellow can think of a good
algorithm.
Guys, this is a little crazy. When the reference count goes to zero, the
object goes away. That's the point of reference counting. If an object is
reference counted, it shouldn' have a destroy method or a public destructor.
And, of course, a provider has exactly the same semantics as the Y-valv
Hi Jim,
can you explain more about your algorithm for "self-describing value
encoding" ?
I'm interesting in this.
Thank you Slavek
Ing. Slavomir Skopalik
Executive Head
Elekt Labs s.r.o.
Collection and evaluation of data from machines and laboratories
by means of system MASA (http://www.elekt
Not correct delete
--
Key: CORE-4697
URL: http://tracker.firebirdsql.org/browse/CORE-4697
Project: Firebird Core
Issue Type: Bug
Affects Versions: 2.5.3
Environment: Windows
Reporter: Dmitry Kornilov
The encoding works like this: Each value consists of a type code followed
by zero or more bytes. For integers, there are type codes for a range of
values, say -10 to 40, and codes for integers of length 1 to 8. For
strings, there are type codes for strings from, say, 0 to 40 bytes,
followed imme
Hi Jim,
thank you very much.
If I understand correctly,
you recomend to have record structure like this:
1. format version
2. nulls flags (each byte will code 8 fields, only nullable fields will
have flag)
3. tr_id (encoded same way as other integer)
4. Only not null field encoded.
For examp
Encode null as a value type and skip the null flags altogether -- saves a
couple of bytes for every record.
I'd encode the format version as the first value. That will let you have
2^63 format versions, which should be enough.
I'd getvthe transaction id in the record header rather than the record
On 23/02/2015 16:36, James Starkey wrote:
> Encode null as a value type and skip the null flags altogether --
> saves a couple of bytes for every record.
>
> I'd encode the format version as the first value. That will let you
> have 2^63 format versions, which should be enough.
>
> I'd getvthe tran
Is that a problem or an inconvience? But if you can't figure out how to
make it work, put in an arbitrary limit. Just remember that there is a
huge difference between not being able to do something and not being able
to do something efficiently given limit resources.
In practice nobody is going t
typing "add -user SYSDBA -pw masterkey -admin yes" into gsec crashes
firebird.exe
-
Key: CORE-4698
URL: http://tracker.firebirdsql.org/browse/CORE-4698
Project: Firebird
On 23.2.2015 20:36, James Starkey wrote:
> Encode null as a value type and skip the null flags altogether -- saves a
> couple of bytes for every record.
I think to use flags only for nullable fields.
In this case, you will lost one byte per each NULL field, but only when
is it NULL, I will be lost
On Monday, February 23, 2015, Slavomir Skopalik
wrote:
> On 23.2.2015 20:36, James Starkey wrote:
> > Encode null as a value type and skip the null flags altogether -- saves a
> > couple of bytes for every record.
> I think to use flags only for nullable fields.
> In this case, you will lost one
16 matches
Mail list logo
