Нека уточним, че Firebird и Interbase вече не са едно и също нещо. Borland зарязаха Classic-архитектурата(CS) и се съсредоточиха върху SuperServer(SS)-архитектурата...Firebird засега поддържат и двете - дали ще е така и в бъдеще? - казват че имат проблеми с финансирането, за да поддържат 2 различни архитектури - единствения приход, който реализират е от продажба на документацията на CD-та..

>I za men stranno no po neiasni prichini count(*) ot tablica s 6,000 zapisa e v pati po bavno ot sastia select v/u tablica s 10,000 zapisa...
Това най-вероятно е проблем на т.нар. GarbageCollection, т.е. ако изтриеш 3млн. записи с Delete-заявка (изпълнява се да кажем за 1сек) и след това стартираш Select, който ти връща 3 записа - може да чакаш и минута(и). Не можах да разбера дали е оправено вече?
И аз съм фен на StoredProcedures - май повече отколкото трябва...

Ето тестове, които е правил член на екипа CoreDevelopers (брей, много руснаци участвуват?!?!):
> Certainly "Classic" has three well known advantages: SMP,
> failure safety, and the ability to kill a runaway process.
> It's a cheap way to get SMP - but it doesn't scale. In
> particular, classic puts more load on the I/O channels -
> there comes a point where the database is simply I/O bound
> and adding more processors isn't going to help.

It scales. I tested it hard. FireBird1 server i configured
handles load from 3000 concurrent users via ~100 active pooled
connections 10 hours a day 7 days a week in production environment
for more than a year on a 8-way SMP machine (Linux RedHat 7.0).
As I remember that configuration - buffer cache was essentialy
disabled. OS file cache was huge (~2 GB, but much less than database
size). No IO bottlenecks where encountered at all, notwithstanding
that it was hybrid OLAP/OLTP database.