On Mon, Dec 12, 2011 at 2:40 PM, Carlos H. Cantu wrote:
> Hi!
>
> For what I'm reading, it seems that FB 3.0 has new OO API.
>
> Afair, in past discussions, the major "limitation" of enhancing the
> currently FB protocol was the "old" API. So, if FB 3 will have a new
> API (so probably component d
One year ago, when I was discussing this with Vlad, I did small
Delphi app using ZeosDB components to measure speed between FB and
MySQL similar databases with same data, hosted on remote computer and
acessing by adsl connection. Results proved that MySQL response was
much faster. From my conversat
> Speed is one of the most important feature so i think it should be
> pushed again and again :)
>
> If you have some ideas please send them to the list even if they are
> in Delphi (Pseudo Code)
Currently work with BLOBs is slow. I'd suggest to merge packets for
open_blob-get_segment-close_bl
14.12.2011 20:02, Carlos H. Cantu wrote:
> Vlad, 06/12/2010 16:24:51:
> could you edit firebird.conf at both client and server hosts and set
> TcpRemoteBufferSize = 32700
> ?
>
> ok, much better (but still worse than MySQL):
> [06/12/2010 16:27:47] Opening FB Query and fetching all data ()
> [06/1
14.12.2011 18:00, Dmitry Yemanov wrote:
> This implicitly suggests that a bigger value of the network packet could
> improve the performance even more, perhaps down to the MySQL's almost
> three seconds.
Only for massive fetches. Performance of big number of small queries cannot
be improved
t
14.12.2011 21:09, Dimitry Sibiryakov wrote:
> Only for massive fetches. Performance of big number of small queries cannot
> be improved
> this way.
They won't perform worse either. And I was replying to the example where
MySQL was faster in fetching rows.
Dmitry
-
14.12.2011 18:24, Dmitry Yemanov wrote:
> They won't perform worse either. And I was replying to the example where
> MySQL was faster in fetching rows.
Yes. But it was rather artificial example which you can hardly find in real
applications.
On the other hand, if you remove overhead of alig
14.12.2011 21:30, Dimitry Sibiryakov wrote:
>
> On the other hand, if you remove overhead of alignment from network protocol,
> both
> types of applications will win.
I'd say they will crash (on non-Intel platforms) instead.
Dmitry
--
14.12.2011 18:46, Dmitry Yemanov wrote:
> I'd say they will crash (on non-Intel platforms) instead.
If you access raw values right in network buffer - yes. But if you use utils
from
memory_routines.h it won't happen.
--
SY, SD.
---
Program received signal SIGSEGV, Segmentation fault.
0x74713f8f in (anonymous
namespace)::AttachmentHolder::AttachmentHolder (this=0x7fffcea0,
tdbb=0x7fffcd78, ja=0x77f22af0, lockAsync=true) at
/home/asfernandes/fb/dev/trunk.git/src/jrd/jrd.cpp:437
437
Recursive CTE returns less rows when using aggregate subquery
-
Key: CORE-3698
URL: http://tracker.firebirdsql.org/browse/CORE-3698
Project: Firebird Core
Issue Type: Bug
Affect
All,
As I said before, ext4 performance with FW=ON is much slower than ext3,
but I now found something new.
I've verified that with FB 2.5, TCS times was ok (0s - 3s), and only
with FB 3 they are very bad (first test takes 16s, then 12s, 8s, 7s, 7s,
etc)
What I found is that:
Times was bad only
After gbak -b system memory will not be released
-
Key: CORE-3699
URL: http://tracker.firebirdsql.org/browse/CORE-3699
Project: Firebird Core
Issue Type: Bug
Components: GBAK
Aff
13 matches
Mail list logo
