--- In firebird-support@yahoogroups.com, Nando Dessena <nando@d...> wrote:

> Maurice,
>
> ML> I've set the buffer back to 75, stopped and restart my script.
> ML> A bath... a snack... and 30 minutes later, this is the "top"

output...

>
> ML> 30342 mling 15 0 48616 44m 2980 S 0.3 1.1 0:38.35 python
> ML> 30343 firebird 20 0 15000 12m 10m S 65.3 0.3 2:08.87
> ML> fb_inet_server
>
> ML> FB takes about too long and too much CPU to run, compared with the
> ML> calling script.
>
> According to my experience, what makes firebird eat cospicuous
> amounts of CPU cycles is usually:
> - scanning indexes with lots of duplicates.
> - scanning records with many backversions (i.e. garbage).
> - sorting (much less than the other two items).
>
> So, I guess the solution for your issue has to pass through analysis
> of the SQL query or queries you are executing, their PLAN, the
> database structure (indexes, etc.) and possibly database statistics
> (run gstat -h on the database and report back here).

No idea what you are trying to ask but here is the gstat -h on the
database...

Database "muscopedia.fdb"

Database header page information:
Flags 0
Checksum 12345
Generation 1575823
Page size 4096
ODS version 10.1
Oldest transaction 1569535
Oldest active 1569536
Oldest snapshot 1569533
Next transaction 1575795
Bumped transaction 1
Sequence number 0
Next attachment ID 0
Implementation ID 19
Shadow count 0
Page buffers 75
Next header page 0
Database dialect 3
Creation date Jul 4, 2005 12:07:21
Attributes

Variable header data:
Sweep interval: 20000
Continuation file:
/mnt/disk/home/mling/muscorian/BioDatabases/muscopedia.fd2
Last logical page: 500000
*END*


cheers
Maurice