On 11/04/13 13:11, Mark Rotteveel wrote:
> On Mon, 04 Nov 2013 11:25:56 +0400, Alex wrote:
>> On 11/03/2013 07:09 PM, Mark Rotteveel wrote:
>>> On 3-11-2013 16:05, Mark Rotteveel wrote:
I am not sure if this behavior is desirable or correct. Based on the
documentation ("Enabled behavior
On 11/04/13 11:23, Alex wrote:
> On 11/03/2013 07:48 PM, Mark Rotteveel wrote:
>> On 3-11-2013 16:05, Mark Rotteveel wrote:
>>> I was still running against the FB 3 Alpha 1 and just upgraded to
>>> 3.0.0.30708 by overwriting my Firebird 3 Alpha 1 install except
>>> firebird.conf and security3.fdb.
On 11/01/13 16:30, Dimitry Sibiryakov wrote:
> 01.11.2013 11:49, Alex Peshkoff wrote:
>> On 10/29/13 20:01, Dimitry Sibiryakov wrote:
>>> Hello, All.
>>>
>>> Did someone try to cut subj off and feed metadata from system tables
>>> directly every
>>> time when they are needed?
>> May be
On 4-11-2013 11:09, Vlad Khorsun wrote:
>> I have a desktop, database is written to a RAID-0 (striped).
>
> Could you made events trace with ProcessMonitor ?
https://www.dropbox.com/s/gzwppacaya1qyme/ProcMon_FB_CreateDatabase.7z
Is this sufficient?
I included a trace with 30556 (Alpha 1) an
On Mon, 4 Nov 2013 12:09:37 +0200, "Vlad Khorsun"
wrote:
>> I have a desktop, database is written to a RAID-0 (striped).
>
> Could you made events trace with ProcessMonitor ?
I will try tonight or later this week.
Mark
---
> I have a desktop, database is written to a RAID-0 (striped).
Could you made events trace with ProcessMonitor ?
Regards,
Vlad
--
Android is increasing in popularity, but the open development platform that
developers
On 04/11/2013 07:52, Vlad Khorsun wrote:
>>> PS Adriano already complains about slowness of CREATE DATABASE in fb3 (see
>>> thread
>>> "Reason for slow CREATE DATABASE in FB 3 (Linux)" started at 15 dec
>>> 2011), i'll look
>>> at it again in a next few days.
>>>
>>> As far as I remember, at
On Mon, 04 Nov 2013 10:48:16 +0100, Dimitry Sibiryakov
wrote:
> 03.11.2013 23:12, Vlad Khorsun wrote:
>> I made almost the same trace of events and i see that my IO
>> subsystem is much faster then
>> yours (or yours is too slow). For example both traces contains 52
>> FlushBuffersFile e
>> PS Adriano already complains about slowness of CREATE DATABASE in fb3 (see
>> thread
>> "Reason for slow CREATE DATABASE in FB 3 (Linux)" started at 15 dec
>> 2011), i'll look
>> at it again in a next few days.
>>
>> As far as I remember, at least one issue was related with changed
>> de
03.11.2013 23:12, Vlad Khorsun wrote:
> I made almost the same trace of events and i see that my IO subsystem is
> much faster then
> yours (or yours is too slow). For example both traces contains 52
> FlushBuffersFile events (i.e.
> they could be considered equal) but summary duration in yo
On 04/11/2013 05:33, Alex wrote:
>
> PS Adriano already complains about slowness of CREATE DATABASE in fb3 (see
> thread
> "Reason for slow CREATE DATABASE in FB 3 (Linux)" started at 15 dec
> 2011), i'll look
> at it again in a next few days.
>
> As far as I remember, at least one issue was
>> PS Adriano already complains about slowness of CREATE DATABASE in fb3
> (see
>> thread
>> "Reason for slow CREATE DATABASE in FB 3 (Linux)" started at 15 dec
>> 2011), i'll look
>> at it again in a next few days.
>
> As Alpha 1 doesn't show this performance problem, it is either a
> re
On Mon, 04 Nov 2013 12:27:14 +0400, Dmitry Yemanov
wrote:
> 04.11.2013 11:21, Alex wrote:
>
>> On the other hand, taking into an account that old API means first of
>> all backward compatibility, may be we should better keep legacy
behavior?
>
> I'd say that getting plan or statistics or any oth
On Mon, 4 Nov 2013 00:12:36 +0200, "Vlad Khorsun"
wrote:
> PS Adriano already complains about slowness of CREATE DATABASE in fb3
(see
> thread
> "Reason for slow CREATE DATABASE in FB 3 (Linux)" started at 15 dec
> 2011), i'll look
> at it again in a next few days.
As Alpha 1 doesn't sho
On Mon, 04 Nov 2013 11:25:56 +0400, Alex wrote:
> On 11/03/2013 07:09 PM, Mark Rotteveel wrote:
>> On 3-11-2013 16:05, Mark Rotteveel wrote:
>>> I am not sure if this behavior is desirable or correct. Based on the
>>> documentation ("Enabled behavior depends another side requirements. If
>>> both
On Sun, 3 Nov 2013 21:03:37 +0200, "Vlad Khorsun"
wrote:
>> 03.11.2013 18:52, Vlad Khorsun wrote:
Yes, isql shows the same behavior.
>>> I can't reproduce it with just build fb3
>>
>> I can.
>> Just unpacked today's snapshot, run 'fbserver -a',
>
> There is no "fbserver" in fb
04.11.2013 11:21, Alex wrote:
> On the other hand, taking into an account that old API means first of
> all backward compatibility, may be we should better keep legacy behavior?
I'd say that getting plan or statistics or any other info about
unprepared (read: unknown) statement is nonsense and I
On 11/03/2013 05:01 PM, Mark Rotteveel wrote:
> On 31-10-2013 17:31, Alex Peshkoff wrote:
>> On 10/31/13 20:20, liviusliv...@poczta.onet.pl wrote:
>>> Hi,
>>>
>>> We store in thouse fields data usefull for application logic. Some dep info
>>> or sime restriction. This was choose of project design
18 matches
Mail list logo
