| Subject | Re: [firebird-support] Re: Basic tests shows very poor performance |
|---|---|
| Author | Pavel Cisar |
| Post date | 2005-09-30T11:28:34Z |
grostoon wrote:
most horrible scenario (all table data were taken out, with multiple
indices with lot of duplicates, in fact, all duplicates, and have to be
discovered (and in some cases removed) at once due to full table scan).
Everyone who uses Firebird knows that, and in most cases it's easy to
avoid it. A ZAP TABLE SQL command that would drop all data and index
B-trees by simply deallocating these db pages would fix all that, and
would make such operation instant. It was discussed in FB-architect
lists, and sometime in the future we would probably implement it, but
it's a low priority feature.
best regards
Pavel Cisar
IBPhoenix
>Again, you have witnessed the automatic garbage collection in action on
> FIREBIRD 1.53 ----------------------
>
> delete from tbl1 : 1.68 s
>
> select count(*) tbl1 : 2430 s !!!
>
> Seriously, spending 45 minutes to discover that a table is actually
> empty for a database of less than 50Mo, it's all but a normal
> behaviour even for a scenario that, I admit it, is not representative
> of real database access...
most horrible scenario (all table data were taken out, with multiple
indices with lot of duplicates, in fact, all duplicates, and have to be
discovered (and in some cases removed) at once due to full table scan).
Everyone who uses Firebird knows that, and in most cases it's easy to
avoid it. A ZAP TABLE SQL command that would drop all data and index
B-trees by simply deallocating these db pages would fix all that, and
would make such operation instant. It was discussed in FB-architect
lists, and sometime in the future we would probably implement it, but
it's a low priority feature.
best regards
Pavel Cisar
IBPhoenix