Re: [Firebird-devel] Transactional Metadata (was: Planning the post v3 development)

2014-05-02 Thread Dimitry Sibiryakov
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

[Firebird-devel] [FB-Tracker] Created: (CORE-4416) FB craches when attempt to create index with key length > 3375 bytes (charset = NONE) when database page_size = 16384

2014-05-02 Thread Pavel Zotov (JIRA)
FB craches when attempt to create index with key length > 3375 bytes (charset = NONE) when database page_size = 16384 - Key: CORE-4416 URL: http://

Re: [Firebird-devel] Feature request & discussion (Reply to Planning the post v3 development)

2014-05-02 Thread Leyne, Sean
> > 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

Re: [Firebird-devel] Feature request & discussion (Reply to Planning the post v3 development)

2014-05-02 Thread Jim Starkey
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

[Firebird-devel] [FB-Tracker] Created: (CORE-4417) gbak: cannot commit index ; primary key with german umlaut

2014-05-02 Thread Oliver Wurdak (JIRA)
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

Re: [Firebird-devel] Feature request & discussion (Reply to Planning the post v3 development)

2014-05-02 Thread Vlad Khorsun
> 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

Re: [Firebird-devel] Feature request & discussion (Reply to Planning the post v3 development)

2014-05-02 Thread Dmitry Yemanov
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

Re: [Firebird-devel] Feature request & discussion (Reply to Planning the post v3 development)

2014-05-02 Thread Jim Starkey
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