Subject | Re: FB 2.1 |
---|---|
Author | tomc7777777 |
Post date | 2009-01-22T09:29:30Z |
--- In firebird-support@yahoogroups.com, Dmitry Yemanov <dimitr@...>
wrote:
number of strengths over many other DB products. This is not meant to
be negative towards FB but constructive.
However, if there is enough data being queried and you are incurring
joins plus involving multiple indexes then you have to tweak the SQL
dependant upon the indexes that are being engaged by the where clause.
This should be unnecessary, or an incredibly rare thing to have to do.
I actually feel this is such a problem that developers from other
products probably come across this 'anomaly' quite quickly and it
makes them reject FB. I should qualify by saying this is only a hunch
though.
Therefore the above is, IMO, a definite problem and to deny its
significance is actually of great concern.
Tom
wrote:
>tries
> tomc7777777 wrote:
> >
> > Ok, but is there not a well-known problem that crops up when FB
> > to combine multiple indexes on a single table through bitmappingthe
> > matching index entries (or some similar technique)?First off, in my experience FB is generally superb, with a great
>
> Sometimes (rarely) it could be a problem. Generally it isn't.
>
>
> Dmitry
>
number of strengths over many other DB products. This is not meant to
be negative towards FB but constructive.
However, if there is enough data being queried and you are incurring
joins plus involving multiple indexes then you have to tweak the SQL
dependant upon the indexes that are being engaged by the where clause.
This should be unnecessary, or an incredibly rare thing to have to do.
I actually feel this is such a problem that developers from other
products probably come across this 'anomaly' quite quickly and it
makes them reject FB. I should qualify by saying this is only a hunch
though.
Therefore the above is, IMO, a definite problem and to deny its
significance is actually of great concern.
Tom