30.04.2014 13:50, Molnár Attila wrote:
*SIZE OF CHAR/VARCHAR domain or variable name, SCALE OF NUMERIC
domain or variable name*
- SIZE OF : returns max CHAR/VARCHAR length or NUMERIC precision,
SCALE OF : return scale of NUMERIC
- gain : by defining a variable with DOMAIN or TYPE
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
picture?
FB craches when attempt to create index with key length 3375 bytes (charset =
NONE) when database page_size = 16384
-
Key: CORE-4416
URL:
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
location.
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
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
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 map to
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 for each
