29.04.2014 12:48, Alex Peshkoff wrote:
> It's about reading table data from page cache when prepare gets slower
> many times. If system table is not in page cache it will be hundreds
> times slower.
Yes, this particular piece of code. But how big % of execution time it takes
in greater
pictur
FB craches when attempt to create index with key length > 3375 bytes (charset =
NONE) when database page_size = 16384
-
Key: CORE-4416
URL: http://
> > Using an index may not help:
> >
> > 1- an index is stored without regard to physical disk location, so using it
> > will
> create a huge amount of random disk IO. Whereas a NATURAL scan follows
> the table.
>
> It depends. Primary key may be stored more-or-less in regard to physical disk
On 5/1/2014 11:45 PM, Dmitry Yemanov wrote:
> 2- In an version based database like Firebird each row will need to be read
> to confirm the current value of the target field.
> It's not about version based databases, it's just about our index
> implementation. And there are possibilities to avoid r
gbak: cannot commit index ; primary key with german umlaut
---
Key: CORE-4417
URL: http://tracker.firebirdsql.org/browse/CORE-4417
Project: Firebird Core
Issue Type: Bug
Comp
> OK, the alternative to record lookups is to store the transaction id in
> index. This would require an index insertion for all indexes defined on
> a table even if the key value didn't change. It would also require a
> corresponding index deletion for each index defined on the table when a
02.05.2014 22:03, Leyne, Sean wrote:
>
>> It depends. Primary key may be stored more-or-less in regard to physical disk
>> location. And the measure how good is INDEX vs NATURAL scan can be
>> available to the optimizer (index clustering factor).
>
> Without the knowledge of way that Primary Keys m
On 5/2/2014 3:25 PM, Vlad Khorsun wrote:
>> OK, the alternative to record lookups is to store the transaction id in
>> index. This would require an index insertion for all indexes defined on
>> a table even if the key value didn't change. It would also require a
>> corresponding index deletion fo