This is not a bug, but a documented feature. list() returns BLOB. And blobs are
distict because BLOB_ID-s are compared.
SELECT DISTINCT, ORDER BY and GROUP BY work on the BLOB ID, not the contents.
https://firebirdsql.org/refdocs/langrefupd21-blob.html
Hi!
One of our customer's firebird.log contains a bunch of this message.
What is this means?
FABIANLIBRASRVThu Oct 17 12:42:18 2019
going blob (0:25677) is not owned by relation (id = 548),
ignored
FABIANLIBRASRVThu Oct 17 12:42:18
OK, I understand now. Thank you.
So HAVING condition is evaluated for EACH ROW instead of just on the group?
I think then the current approach is wrong in the engine.
http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt
http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt
"2) The is applied to each group of
Hi!
SELECT
e.emp_no
FROM employee e
JOIN employee_project p ON p.emp_no = e.emp_no
GROUP BY e.emp_no
HAVING MAX((SELECT
SUM(e2.salary)
FROM employee e2
JOIN employee_project p2 ON p2.emp_no = e2.emp_no
WHERE
Software raid and hardware raid without BBU has a huge performace hit :
https://ib-aid.com/en/articles/45-ways-to-speed-up-firebird-database/
https://ib-aid.com/en/articles/45-ways-to-speed-up-firebird-database/
EXT3, EXT4 : file system barrier property has huge performance hit
Hi!
Before 2.5.9 mon$attachments.mon$remote_address returned just IP, e.g.:
"192.168.0.1".
With 2.5.9 it returns IP + port number, e.g.: "192.168.0.1/55970".
It made broke some of our code. (We are comparing mon$remote_address to outer
source IP without port)
It this intentional, a
Hi!
We use 2.5.8 CS on Oracle Linux 7.6. It has 200+ database and 4000+
connections.
Yesterday we had corruptions in many databases around the same moment.
These are the different messages in the firebird.log after the corruptions and
trying to valdate/fix/backup/restore/read the
Hi!
Do not use software RAID, it has no disc cache and IO becomes terribly slow.
You have to use harware RAID with BBU ho have disc cache and good performance.
Hi!
You have to make some changes in xinetd.
service gds_db
{
disable = no
flags = reuse
socket_type = stream
wait = no
tcps = 50 10
user = firebird
per_source = UNLIMITED
instances = UNLIMITED
server = /opt/firebird/bin/fb_inet_server
}
Hi!
You cannt have expression in unique key, but you can have expression index with
unique property. ;)
This is not a bug, this is expected behaviour : sweep/garbage collection
occures.
Hi!
Firebird does not like ext4.
http://www.firebirdnews.org/forced-writes-performance-impact-on-ubuntu/
http://www.firebirdnews.org/forced-writes-performance-impact-on-ubuntu/
http://www.firebirdnews.org/understanding-barrier-on-linux/
Hi!
TCP connections are limited in xinetd.
Edit /etc/xinet.d/firebird file
service gds_db
{
disable = no
flags = reuse
socket_type = stream
wait = no
tcps = 50 10
user = firebird
per_source = UNLIMITED
instances = UNLIMITED
server = /opt/firebird/bin/fb_inet_server
}
Hi!
#1 : FB does not like ext4 : Firebird News » Forced Writes Performance impact
on #Ubuntu with ext4 no barrier
http://www.firebirdnews.org/forced-writes-performance-impact-on-ubuntu/
http://www.firebirdnews.org/forced-writes-performance-impact-on-ubuntu/
Firebird News » Forced Writes
15 matches
Mail list logo
