At 12:39 02/02/2004 -0500, you wrote:

... snip ...

> >I though that because FB indexes are compressed (RLE Encoded AFAIR) one
> >could not traverse on the reverse way.
>
>It's not RLE, it's prefix and suffix compression. Trailing spaces
>in text keys and trailing zeros are compressed in numeric (double
>precision) keys. The prefix compression eliminates all leading
>bytes that duplicate the preceding key value.
>
>Prefix compression is not performed on the first node on each
>page. You can't walk a single page backward, but you can - or
>could absent concurrency issues - walk the leaf level backward.

Ann, one mor time, thank you for your explanations... I really like to read
your comments..

> >Do we still needs compressed indexes ?
> >What we have:
> >1.) More entries per index page (very good)
> >2.) Index uses less space (disk space should be treated as high priority
> >nowadays ?)
>
>It's not space, its the I/O load. More entries per page -> fewer
>reads to get an index range.

Ok... So item 1 (More entries per index page (very good))... is the real
reason... Crystal clear....

> >An option on create index statement to not compress could be a choice ?
>
>No - compression is not the reason why you can't walk the right side
>of an index. Concurrent activity is the reason.

ok well explained above....

> >The index could be stored compressed on disk-data-page, but once read the
> >cached-page could store the uncompressed version of the same page ? If so,
> >once those pages are in memory could we use the index on both directions ?
>
>As above. That's not the problem
>
> > David Johnson again.
> > > In this case, may also be identifying a minor weakness in the
> > > optimizer. Without changing the basic design premise, Count(*) should
> > > run against the index with the smallest footprint that is guaranteed to
> > > include pointers to all rows rather than the table space itself.
>
>As above, not true.
>
>Alexandre Benson Smith wrote:
>
> >I have asked once why FB does not use just the index when some select asks
> >just for indexed columns like:
> >
> >select name from person where name like 'Ale%'
>
>In that case, it will use an index to locate all candidate records,
>but must then read each of the candidates to insure that it does
>actually fall into the set of records available to the transaction.

Yeah... you teached me this some months ago... In my original post I told
to David that I asked the same thing... and why it cannot be
accomplished... Understood...

> >I thought we could have diferent kinds of tables (memory table for
> >example), indexes (compressed, uncompressed, b*tree, hash, clustered (a la
> >MSSQL), etcs...)
>
>One of the major design goals for Firebird was simplicity and part
>of simplicity is finding the best way to work with a limited set of
>tuning parameters. In your list above, the only thing I agree with
>is memory tables, and even then, I'm not at all sure they're necessary.
>I see no benefit to uncompressed indexes. Bitmap index access greatly
>reduces the need for clustered indexes without introducing the need
>for the database designer to see into the future when defining his
>table structures. And bitmap index access works for all indexes, not
>just the primary key. Hash indexes are fine in memory, but an untuned
>hash index is worse than no index at all.

I love Firebird simplicity... and HATE Oracle monstruosity (a manual with
more than 1000 pages named "getting started" makes me laught).

What I intended to say was:

With FB 2.0 we "could" (not will) get different kinds of indexes and
tables, I think could be cases when a Clustered Index could be better, and
will be easier to fellow FB developers to implement diferent approachs to
search, storage, etc... could be a super classes to abstract the
implementation details. I don't know if implement another kind of index
will be better for FB performance (besides other RDBMS does different kinds
of index, FB uses MGA the others don't... so the best for Oracle
architeture sould be the worst for FB)... Only her mother knows... :-).

I think that if different kinds of indexes could bring better performance
in some kind of tables, will be good if FB implements those, keeps b*tree
by default if it's the best for overall uses, but have a choice is better
than don't one...

The best part of this discussion (or better your discurse)... is that I can
learn a lot... :)

>Regards,
>
>
>Ann

See you, I thank you again to tell us how "your son" works...


Alexandre Benson Smith
Development
THOR Software e Comercial Ltda.
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br

----------


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.576 / Virus Database: 365 - Release Date: 30/01/2004


[Non-text portions of this message have been removed]