[Firebird-devel] [FB-Tracker] Created: (CORE-4696) No need to flush dirty pages to disk after creation of temporary table index
No need to flush dirty pages to disk after creation of temporary table index Key: CORE-4696 URL: http://tracker.firebirdsql.org/browse/CORE-4696 Project: Firebird Core Issue Type: Improvement Components: Engine Affects Versions: 2.5.3 Update 1, 2.1.7, 3.0 Beta 1, 2.5.3, 2.1.6, 3.0 Alpha 2, 3.0 Alpha 1, 2.5.2 Update 1, 2.1.5 Update 1, 2.5.2, 2.5.1, 2.5.0 Reporter: Vlad Khorsun Priority: Minor When temporary table instance is physically created engine creates also all it's indices. When index is created and b-tree is fully populated with data engine flushes its cache to disk. It is obviously not needed step when we created (empty) index of temporary table instance. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Possible response on the asynchronous port (event connection)
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_disconnect, op_event and op_response I'd like to know two things: 1) Is it indeed possible that op_response is sent over the event connection (and if so, under what conditions)? 2) are there other operations I should take into account? Mark -- Mark Rotteveel -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Provider objects has different semantics than y-valve objects
22.02.2015 18:35, Adriano dos Santos Fernandes wrote: So you have: IBlob* blob = ...-openBlob(...); blob-cancel(); // no leak Using of smart pointers here makes life even funnier. IMHO, it is Y-valve bug. But in absence of API specifications it is rather as expected. -- WBR, SD. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Provider objects has different semantics than y-valve objects
On 22-02-2015 14:51, Dimitry Sibiryakov wrote: 22.02.2015 18:35, Adriano dos Santos Fernandes wrote: So you have: IBlob* blob = ...-openBlob(...); blob-cancel(); // no leak Using of smart pointers here makes life even funnier. IMHO, it is Y-valve bug. But in absence of API specifications it is rather as expected. A solution must be to pass a parameter to destroy methods specifying if they should release or not the object. And of course, all implementations should follow it. So with or without smart pointers, use may be more intuitive. Adriano -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Provider objects has different semantics than y-valve objects
22.02.2015 19: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. More dragon poker - more fun. And of course, all implementations should follow it. So with or without smart pointers, use may be more intuitive. Smart pointer used to call Release() method unconditionally. Letting any other method to destroy object before that will lead to crash. -- WBR, SD. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Recore level compresion imroovement
Hi all,
I was made litle improovement in record level compresion.
Motivation:
- significant dabase grow increase after switch to UTF8
Analysis:
- I was found inefficient algoritmus for compressing zeroes
- I was found, that some control char values are not used
Solution:
- I add to code ability to pack up 32k of zeroes into 2 bytes
without lossing current features.
- New version can read old database, but when write, old version cannot
read.
Result:
DB size: DB with WIN2050 character set was packed from 733MB down to 633MB
Restore speed was increase from 3:06 down to 2:55 minutes.
Select operation was litle bit faster (depends on datafield)
I was made changes in actual trunk for version 2.5.4.
Please, review this code and let me know, I is it interesting for
Firebird community.
Code is not so well optimized and also more effective and faster
algorimus can be used in future.
Best regards 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.elektlabs.cz/m2demo)
-
Address:
Elekt Labs s.r.o.
Chaloupky 158
783 72 Velky Tynec
Czech Republic
---
Mobile: +420 724 207 851
icq:199 118 333
skype:skopaliks
e-mail:skopa...@elektlabs.cz
http://www.elektlabs.cz
/*
* PROGRAM:JRD Access Method
* MODULE: sqz.cpp
* DESCRIPTION:Record compression/decompression
*
* The contents of this file are subject to the Interbase Public
* License Version 1.0 (the License); you may not use this file
* except in compliance with the License. You may obtain a copy
* of the License at http://www.Inprise.com/IPL.html
*
* Software distributed under the License is distributed on an
* AS IS basis, WITHOUT WARRANTY OF ANY KIND, either express
* or implied. See the License for the specific language governing
* rights and limitations under the License.
*
* The Original Code was created by Inprise Corporation
* and its predecessors. Portions created by Inprise Corporation are
* Copyright (C) Inprise Corporation.
*
* All Rights Reserved.
* Contributor(s): __.
*
* Compressed format:
* signed char control_Char playload
Control_Char:
0..127: Uncompressed data in payload of length
Control_Char
-1: 128Bytes block of zeroes, payload
contain one unsigned char, that represents count of these blocks
-2: Reserved for future use
-128..-3 : Compressed data, absolute value of
Control_Char represents how many bytes have to be repeted, payload represent
patern (one byte)
*
*/
#include firebird.h
#include string.h
#include ../jrd/common.h
#include ../jrd/sqz.h
#include ../jrd/req.h
#include ../jrd/err_proto.h
#include ../jrd/gds_proto.h
#include ../jrd/sqz_proto.h
using namespace Jrd;
USHORT SQZ_apply_differences(Record* record, const SCHAR* differences, const
SCHAR* const end)
{
/**
*
* S Q Z _ a p p l y _ d i f f e r e n c e s
*
**
*
* Functional description
* Apply a differences (delta) to a record. Return the length.
*
**/
if (end - differences MAX_DIFFERENCES)
{
BUGCHECK(176); /* msg 176 bad difference
record */
}
SCHAR* p = (SCHAR*) record-rec_data;
const SCHAR* const p_end = (SCHAR*) p + record-rec_length;
while (differences end p p_end)
{
const SSHORT l = *differences++;
if (l 0)
{
if (p + l p_end)
{
BUGCHECK(177); /* msg 177 applied differences
will not fit in record */
}
if (differences + l end)
{
BUGCHECK(176); // msg 176 bad difference record
}
memcpy(p, differences, l);
p += l;
differences += l;
}
else
{
p += -l;
}
}
const USHORT length = (p - (SCHAR *) record-rec_data);
if (length record-rec_length || differences end)
{
BUGCHECK(177); /* msg 177 applied differences
will not fit in record */
}
return length;
}
USHORT SQZ_compress(const DataComprControl* dcc, const SCHAR* input, SCHAR*
output, int space)
{
/**
*
* S Q Z _ c o m p r e s s
*
**
*
* Functional
[Firebird-devel] Provider objects has different semantics than y-valve objects
Hi! Lets call YBlob::cancel, YTransaction::commit, YTransaction::rollback, YEvents::cancel and maybe others as destroy methods. Destroy methods when called in y-valve objects automatically does a release on them. So you have: IBlob* blob = ...-openBlob(...); blob-cancel(); // no leak On the other hand, in engine provider, destroy methods does not release the objects: IBlob* blob = ...-openBlob(...); blob-cancel(); // leak blob-release(); // no leak I think the release/no-release semantics must be an interface contract, and all implementations must respect it. For example, currently we have InternalDS and IscDS classes that today (after providers are created) are pretty redundant. Some day they could be merged. But if one works directly with engine provider (like now) and another works with y-valve, we'd need very non-intuitive code to manage this. Adriano -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Recore level compresion imroovement
22.02.2015 20:19, Slavomir Skopalik wrote: I was made litle improovement in record level compresion. Motivation: - significant dabase grow increase after switch to UTF8 Analysis: - I was found inefficient algoritmus for compressing zeroes - I was found, that some control char values are not used Solution: - I add to code ability to pack up 32k of zeroes into 2 bytes without lossing current features. - New version can read old database, but when write, old version cannot read. Result: DB size: DB with WIN2050 character set was packed from 733MB down to 633MB Restore speed was increase from 3:06 down to 2:55 minutes. Select operation was litle bit faster (depends on datafield) I was made changes in actual trunk for version 2.5.4. Please, review this code and let me know, I is it interesting for Firebird community. I didn't look at the code closely, but the idea is more or less the same as I was considering for CORE-4401. I just wanted to use the control char of zero for that purpose, as it's practically useless for either compressible or non-compressible runs. The new encoding affects the ODS, so it cannot be used in the v2.5 series (it may be possible with ODS 11.3 but I don't think we need a minor ODS change in v2.5). But it surely could be applied to v3 after review and we don't have to worry about backward compatibility in ODS 12. Dmitry -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Possible response on the asynchronous port (event connection)
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_disconnect, op_event and op_response I'd like to know two things: 1) Is it indeed possible that op_response is sent over the event connection (and if so, under what conditions)? 2) are there other operations I should take into account? Looking at our code, I see that only op_event, op_exit and op_disconnect are processed, others are ignored. I do remember that op_dummy can also be sent, but it acts as no-op so it's OK to ignore it. I doubt op_response can appear there. Dmitry -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
