Subject | Re: [Firebird-Architect] blobs causes table fragmentation. |
---|---|
Author | Alexandre Kozlov |
Post date | 2004-10-05T13:16:17Z |
Ann,
----- Original Message -----
From: "Ann W. Harrison" <aharrison@...>
To: <Firebird-Architect@yahoogroups.com>;
<Firebird-Architect@yahoogroups.com>
Sent: Monday, October 04, 2004 4:06 PM
Subject: Re: [Firebird-Architect] blobs causes table fragmentation.
>
> At 11:24 AM 10/4/2004, Alexandre Kozlov wrote:
>
>
> >3) Simple "SELECT COUNT(*) FROM LargeTable" will probably may take hours
(of
> >course, after cache stabilized it will take just about 1 minute)
>
> OK, and if you really really care about how long it takes to count
> all the records in a large table, you probably should either use
> a different database, or find some way to maintain the count without
> having to touch every record. In Firebird, SELECT COUNT (*) is not
> a simple operation, it's a simplistic performance trap, which real
> programs solving real problems never use. Tuning the system, or
> complicating the system tuning to improve SELECT COUNT(*) on a large
> table with an empty cache is a waste of time.
Good explanation. Mentioning SELECT COUNT(*) statement was just as a one of
a kind that scanning the whole table and you are right, from the point of
view of user application performance it looks quite queery to allow him/her
to scan the whole largest table. And your (and Jim) opinion about adding
features related with "physical optimization" well known to me. And probably
you are right in this specific case. But:
1) what if DBA need some scanning for some reparing purpose (when cache is
empty) ? And list can be continued.
2) this feature looks very naturally, usefull for large table and optional.
3) it looks like not dificult for implementation if to enter possibility of
adding not default data files for some tables.
4) and I do not agree with total approach of rejecting some similar
"physical optimization" features. This database is needed now not in the far
future. And most probably for enterprise grade.
Thank you,
Alexander
>
> Regards,
>
>
> Ann
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
> E1-I: This message has been scanned for viruses and dangerous content by
UML's antivirus scanning services.
>
>
>