[Firebird-devel] [FB-Tracker] Created: (CORE-5127) GBAK should be able to make a backup of firebird files with previus ODS.

GBAK should be able to make a backup of firebird files with previus ODS. -- Key: CORE-5127 URL: http://tracker.firebirdsql.org/browse/CORE-5127 Project: Firebird Core

[Firebird-devel] [FB-Tracker] Created: (CORE-5126) Installation of Firebird 3.0 beta 2 totally ignores my sysdba login information

Installation of Firebird 3.0 beta 2 totally ignores my sysdba login information --- Key: CORE-5126 URL: http://tracker.firebirdsql.org/browse/CORE-5126 Project: Firebird Core

Re: [Firebird-devel] RFC: Tablespaces

On 3/3/2016 2:30 PM, les...@lsces.co.uk wrote: Initially when I ran websites, the normal practice was to save everything in the database, pictures, pdf's, documents, and so on. The databases soon got too large and while just having one file to back up was nice, NOT using blobs for that content

Re: [Firebird-devel] Record level compression for V4

1. Data can (already did) at any point, not only at specific, that you marks by '!'. 2. If packed record doesn't fit into one page, control sequence is parsed from end. 3. When rest of sequence will fit, compression is started again from beginning. 4. If fragment has odd length, zero is added.

Re: [Firebird-devel] RFC: Tablespaces

Em 3/3/2016 04:04, Dmitry Yemanov escreveu: > 03.03.2016 09:48, Dmitry Yemanov wrote: >>> Blobs could be moved into separate tablespace. It could make backup of >>> "data" tablespace faster and smaller. We can even think about "offline" >>> tablespace. >> Really good idea. Maybe more important for

Re: [Firebird-devel] Record level compression for V4

Hi Jim, Elekt Labs RLE is ready to use and is better then current one. The best one have to be developed and I will help if I can. The question is still same: Is it right time or will be postponed to V5 (2024+) ? Slavek > > Excuse me, but faster than the current one is not the question. The

Re: [Firebird-devel] RFC: Tablespaces

Em 03/03/2016 13:43, Vlad Khorsun escreveu: > >I would add > > 4. Allow to specify FW and Read-Only settings on per tablespace level > 5. Ability to bring individual tablespace off-line (and back online, of > course) > ... It's not a tablespace feature, but a schema feature integrated

Re: [Firebird-devel] RFC: Tablespaces

Initially when I ran websites, the normal practice was to save everything in the database, pictures, pdf's, documents, and so on. The databases soon got too large and while just having one file to back up was nice, NOT using blobs for that content was a lot easier. Rsync to backup machine,

Re: [Firebird-devel] RFC: Tablespaces

On Thu, Mar 3, 2016 at 1:02 PM, Jim Starkey wrote: > > >> Non-goals: > >> > ... > >> 2. Store blobs in other than the table's data space. > > Why not allow blobs to be separated from regular data ? > > OK, reasonable question. Obviously they could, but it would

Re: [Firebird-devel] RFC: Tablespaces

On 3/3/2016 11:43 AM, Vlad Khorsun wrote: > 03.03.2016 17:57, Jim Starkey wrote: >> The place to start is with a clear, well understood, and agreed set of >> requirements. Here is a suggested starting point. >> >> First, some definitions. A "data space" is the collection of pointer and >> data

Re: [Firebird-devel] RFC: Tablespaces

On Wed, Mar 2, 2016 at 4:51 PM, Vlad Khorsun wrote: > >Blobs could be moved into separate tablespace. It could make backup of > "data" tablespace faster and smaller. We can even think about "offline" > tablespace. > > Interesting idea. I'm not quite sure how it

Re: [Firebird-devel] RFC: Tablespaces

On Wed, Mar 2, 2016 at 4:23 PM, Dmitry Yemanov wrote: > > When we speak about tablespaces, it usually means that the database > consists of multiple files and different database object are stored in > different files. Each such file is named within a database and called a >

Re: [Firebird-devel] Record level compression for V4

On Thursday, March 3, 2016, Dmitry Yemanov wrote: > 03.03.2016 19:16, Jim Starkey wrote: > > > On 3/3/2016 11:10 AM, Dmitry Yemanov wrote: > >> Am I missing something obvious? > > > > Yeah. Data. > > I was not talking about value-based encoding (which surely requires a >

Re: [Firebird-devel] RFC: Tablespaces

03.03.2016 17:57, Jim Starkey wrote: > The place to start is with a clear, well understood, and agreed set of > requirements. Here is a suggested starting point. > > First, some definitions. A "data space" is the collection of pointer and > data pages that hold the data from a single table.

Re: [Firebird-devel] [Firebird-checkins] SF.net SVN: firebird:[63072] firebird/trunk/src

03.03.2016 17:38, Dmitry Yemanov wrote: > Pretty no difference for short hash strings, thanks. Your conslusion is...? -- WBR, SD. -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM +

Re: [Firebird-devel] [Firebird-checkins] SF.net SVN: firebird:[63072] firebird/trunk/src

03.03.2016 17:25, Vlad Khorsun wrote: >> Tests shown no drawback for longer data. > Does you test the code without that two if's ? Yes, I specially compared performance with and without them. Function with these ifs won on short (1-2 bytes) data and shown the same performance

Re: [Firebird-devel] [Firebird-checkins] SF.net SVN: firebird:[63072] firebird/trunk/src

03.03.2016 19:33, Dimitry Sibiryakov wrote: > Original: >> Elapsed time= 1.243 sec vs > CRC32: >> Elapsed time= 1.238 sec Pretty no difference for short hash strings, thanks. Dmitry -- Site24x7 APM Insight: Get Deep

Re: [Firebird-devel] Record level compression for V4

03.03.2016 19:16, Jim Starkey wrote: > On 3/3/2016 11:10 AM, Dmitry Yemanov wrote: >> Am I missing something obvious? > > Yeah. Data. I was not talking about value-based encoding (which surely requires a different approach). Dmitry

Re: [Firebird-devel] [Firebird-checkins] SF.net SVN: firebird:[63072] firebird/trunk/src

03.03.2016 17:13, Dmitry Yemanov wrote: > Can you perform the same test but with INT join key? I made number of records in table i2 four times bigger to get rid of timer's jitter, but still... Original: > SQL> select count(*) from i1 join i2 on i1.a=i2.a; > > PLAN HASH (I2 NATURAL, I1

Re: [Firebird-devel] [Firebird-checkins] SF.net SVN: firebird:[63072] firebird/trunk/src

03.03.2016 16:15, Dimitry Sibiryakov wrote: > 03.03.2016 15:07, Vlad Khorsun wrote: Are you sure that lock manager doesn't work with data of one or two bytes long? At these sizes the function had a weak spot without these ifs. >> Perfect. All other 99% cases (with key >=

Re: [Firebird-devel] Record level compression for V4

On 3/3/2016 11:10 AM, Dmitry Yemanov wrote: > Am I missing something obvious? Yeah. Data. > Dmitry > -- > > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3

Re: [Firebird-devel] [Firebird-checkins] SF.net SVN: firebird:[63072] firebird/trunk/src

03.03.2016 18:36, Dimitry Sibiryakov wrote: > varchar(2000) filled with rpad('', 2000, uuid_to_char(gen_uuid())). Can you perform the same test but with INT join key? Dmitry -- Site24x7 APM Insight: Get Deep

Re: [Firebird-devel] Record level compression for V4

03.03.2016 18:34, Slavomir Skopalik wrote: > > But value encoding cannot be implemented until we switch from fragment > compression to true record level compression. I was not speaking about any encoding, just about compacting the record. Fragments are not compressed independently. The whole

Re: [Firebird-devel] [Firebird-checkins] SF.net SVN: firebird:[63072] firebird/trunk/src

03.03.2016 18:49, Dimitry Sibiryakov wrote: >> Out of curiosity, why do we need a separate crc32c.cpp? > > To let engine work on processors without SSE4.2 command set. Ah, I missed processor-specific compilation flags for that module. Thanks for clarifying. Dmitry

Re: [Firebird-devel] [Firebird-checkins] SF.net SVN: firebird:[63072] firebird/trunk/src

03.03.2016 16:31, Dmitry Yemanov wrote: > I had the same doubts about the first two if's, but > Vlad already asked about them. And as I already said: they improve performance with short data without visible affect for long data. At least two months old tests showed me that. If anyone's tests

Re: [Firebird-devel] [Firebird-checkins] SF.net SVN: firebird:[63072] firebird/trunk/src

03.03.2016 16:20, Vlad Khorsun wrote: >> will you believe my numbers?.. > Why not ? Exactly because of > special case, but very far from real life, i'm afraid. > I guess you have join on long strings. Not much long: varchar(2000) filled with rpad('', 2000,

Re: [Firebird-devel] [Firebird-checkins] SF.net SVN: firebird:[63072] firebird/trunk/src

03.03.2016 14:07, Dimitry Sibiryakov wrote: > Ok, here you have it, attached. Much better, thanks. I had the same doubts about the first two if's, but Vlad already asked about them. Out of curiosity, why do we need a separate crc32c.cpp? Cannot the CRC32C function be defined inside Hash.cpp?

Re: [Firebird-devel] [Firebird-checkins] SF.net SVN: firebird:[63072] firebird/trunk/src

03.03.2016 16:51, Dimitry Sibiryakov wrote: > 03.03.2016 15:07, Vlad Khorsun wrote: >>> I wouldn't expect much from lock manager, but hash joins can get >>> significant boost, especially on long keys. >> You don't need "server with dozen of cores" to check it, isn't is ? > >

Re: [Firebird-devel] RFC: Tablespaces

Vlad proposition is better then writting somethink on every transaction and should work without ovehead look at this (if i understand Vlad's proposition correctly) two fields MAIN_DB_GUID, MAIN_OPENED and the same for all table space files (as S_DB_GUID, S_OPENED) 1. First connect to db 2.

Re: [Firebird-devel] [Firebird-checkins] SF.net SVN: firebird:[63072] firebird/trunk/src

03.03.2016 15:07, Vlad Khorsun wrote: >> I wouldn't expect much from lock manager, but hash joins can get >> significant boost, >> >especially on long keys. > You don't need "server with dozen of cores" to check it, isn't is ? You are right, this part I can test even with my

Re: [Firebird-devel] Record level compression for V4

All, This is how I see the things. RLE is good for record compression due to the following facts: 1) In-memory record has all the fields expanded up to their maximum size. Shorter values are padded with zeroes (that are easy to compress). 2) In-memory record stores the NULL bitmap and at the

Re: [Firebird-devel] RFC: Tablespaces

We use Oracle and table spaces. We specify which drives/drive channels hold which data/tables/indexes to optimize various OLAP/OLTP needs. We also use firebird. We use multiple files as large multi-raid drive arrays have problems in that the larger arrays may have multiple drives fail faster

Re: [Firebird-devel] [Firebird-checkins] SF.net SVN: firebird:[63072] firebird/trunk/src

03.03.2016 15:07, Vlad Khorsun wrote: >> > Are you sure that lock manager doesn't work with data of one or two >> > bytes long? At >> >these sizes the function had a weak spot without these ifs. > Perfect. All other 99% cases (with key >= 4 bytes) must pay for nothing. Tests shown no

Re: [Firebird-devel] [Firebird-checkins] SF.net SVN: firebird:[63072] firebird/trunk/src

03.03.2016 15:32, Dimitry Sibiryakov wrote: > 03.03.2016 12:56, Vlad Khorsun wrote: >>> If you mean overall profit under multiuser load, then - no, I have no >>> numbers for that. >> >> Perfect > > If you have at hand server with dozen of cores and test suite you are > welcome to

Re: [Firebird-devel] Wire protocol changes - was: Record level compression for V4

On 03/03/2016 03:10 PM, Mark Rotteveel wrote: > On 2016-03-03 12:44, Alex Peshkoff wrote: >> On 03/03/2016 12:26 PM, Mark Rotteveel wrote: >> >>> But my main concern >>> has to do with my experience with wire protocol changes in Firebird: >>> they are usually poorly documented, >> Poorly is

Re: [Firebird-devel] Improve compilation on OS X El Capitan

>From what i know current version of LibreOffice from git compiles just fine on El Capitan (Firebird 2.5.5 with a few patches for c++11/14 compilers) you can inspect the latest changes here https://cgit.freedesktop.org/libreoffice/core/log/external/firebird On Thu, Mar 3, 2016 at 7:30 AM,

Re: [Firebird-devel] Wire protocol changes - was: Record level compression for V4

On 2016-03-03 12:44, Alex Peshkoff wrote: > On 03/03/2016 12:26 PM, Mark Rotteveel wrote: > >> But my main concern >> has to do with my experience with wire protocol changes in Firebird: >> they are usually poorly documented, > > Poorly is incorrect word here, remote protocol is not documented at

Re: [Firebird-devel] Browse information in VS 2010

03.03.2016 13:28, Dimitry Sibiryakov wrote: > > Do anybody use subj? Yes, me (sometimes). Dmitry -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App

Re: [Firebird-devel] RFC: Tablespaces

03.03.2016 9:04, Dmitry Yemanov wrote: > 03.03.2016 09:48, Dmitry Yemanov wrote: >> >>> Blobs could be moved into separate tablespace. It could make backup of >>> "data" tablespace faster and smaller. We can even think about "offline" >>> tablespace. >> >> Really good idea. Maybe more important

Re: [Firebird-devel] Browse information in VS 2010

03.03.2016 12:55, Dimitry Sibiryakov wrote: > 03.03.2016 11:52, Vlad Khorsun wrote: >>> Do anybody use subj? >> Sure > > Don't you use VS 2013?.. It have no impact on my opinion Vlad -- Site24x7 APM

Re: [Firebird-devel] [Firebird-checkins] SF.net SVN: firebird:[63072] firebird/trunk/src

03.03.2016 6:28, Dmitry Yemanov wrote: I've asked for a particular change patch, you've provided 220KB of the total tree diff to scan for the needed changes. If you want your patches reviewed sooner, better start to respect other's time. Ok, here you have it, attached. -- WBR, SD.

Re: [Firebird-devel] Browse information in VS 2010

03.03.2016 11:52, Vlad Khorsun wrote: >> Do anybody use subj? > Sure Don't you use VS 2013?.. -- WBR, SD. -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM:

Re: [Firebird-devel] Browse information in VS 2010

03.03.2016 12:28, Dimitry Sibiryakov wrote: > Hello, All. > > Do anybody use subj? Sure > Windows DDK 7.1 does not have browse symbol compiler for 64 bits. Because > of that build > of 64 bits version fail with VS 2010 Express. IIRC, VS 2010 Express have no 64-bit compiler.

[Firebird-devel] Browse information in VS 2010

Hello, All. Do anybody use subj? Windows DDK 7.1 does not have browse symbol compiler for 64 bits. Because of that build of 64 bits version fail with VS 2010 Express. Do you object if I commit changes in project files that turn generation of browse symbols off? -- WBR, SD.

Re: [Firebird-devel] RFC: Tablespaces

03.03.2016 11:10, Atri Sharma wrote: > > > I feel that tablespaces allow managing multiple independent identities > inside a database > > conveniently, and making stuff like backups pretty fast and granular. > > How are you going to solve problem with inconsistency between >

Re: [Firebird-devel] RFC: Tablespaces

> > > I feel that tablespaces allow managing multiple independent identities > inside a database > > conveniently, and making stuff like backups pretty fast and granular. > >How are you going to solve problem with inconsistency between > tablespaces? > > > Which specific inconsistency can you

Re: [Firebird-devel] RFC: Tablespaces

03.03.2016 10:33, Atri Sharma wrote: > Personally, I don't care much about tablespaces per se. But I foresee > that table partitioning could be stacked over the tablespace > implementation and I like this idea. > > > > I feel that tablespaces allow managing multiple independent

Re: [Firebird-devel] Record level compression for V4

> they are usually poorly documented, which creates a large burden on > driver implementers having to follow all intricacies of the code (in my > case in a language that I'm not fluent in) to understand what changes > they need to implement. Especially with code involving encryption or >

Re: [Firebird-devel] RFC: Tablespaces

> > > And another question: does RDB$PAGES need to include the pagespace ID or > we never allow tablespaces for TIP, generator pages and system tables? > Pagespace ID for PP/IRP can be retrieved from RDB$ tables based on > relation_id, so I don't see a problem to store just the "local" page >

Re: [Firebird-devel] RFC: Tablespaces

On Thu, Mar 3, 2016 at 11:01 AM, Dmitry Yemanov wrote: > 03.03.2016 00:23, Dmitry Yemanov wrote: > > > > Someone may think about per-tablespace physical backups and other > > possible usage cases. > > Personally, I don't care much about tablespaces per se. But I foresee >

Re: [Firebird-devel] Record level compression for V4

On 2016-03-03 1:35, Slavomir Skopalik wrote: > Hi, > this is about record encoding . > My private test with RLE + LZ4 shows, that from combination RLE, LZ4, > RLE + LZ4 the last is the best. I'm perfectly ok with doing that for records. > I believe, that better record encoding will help wire

Re: [Firebird-devel] GitHub

On 2016-03-03 1:19, Adriano dos Santos Fernandes wrote: > Em 02/03/2016 11:14, Michal Kubecek escreveu: >> On Wed, Mar 02, 2016 at 10:45:35AM -0300, Adriano dos Santos >> Fernandes wrote: >>> Em 02/03/2016 09:31, Michal Kubecek escreveu: On Wed, Mar 02, 2016 at 02:18:27PM +0300, Dmitry

Re: [Firebird-devel] RFC: Tablespaces

I see that something strange happend with my email. It is broken :( something happened in place "ecod version." -< i do not write this and also at the end i see duplicate lines, cuts and other strange things. Very strange for me... I paste below orginal message

[Firebird-devel] [FB-Tracker] Created: (CORE-5125) Add possibility to mark all pages at e.g. restore time as not writable for new incoming data

Add possibility to mark all pages at e.g. restore time as not writable for new incoming data Key: CORE-5125 URL: http://tracker.firebirdsql.org/browse/CORE-5125

Re: [Firebird-devel] RFC: Tablespaces

Hi, please do not touch shadows. Shadows are used by many organisations. I saw it in almost any of them where i do some job for it. And someone in near past worked on extending its usage e.g. CORE-4955 I agree with you that already existing feature "multi file database" is really "Database

[Firebird-devel] gpre and boolean fields

>Do you agree that support for boolean fields in gpre is a good thing? If somebody provides the support, then I am unlikely to complain, strangely enough I do know a few users who continue to use gpre. Regards Paul