Subject | Re: [ib-support] Data Caching by IB |
---|---|
Author | Helen Borrie |
Post date | 2002-08-24T03:20:20Z |
At 10:18 AM 24-08-02 +0800, you wrote:
returned to the client in packets, the number of which is determined by the
client request. But the resultsets don't outlive the transaction in which
they are generated and they are not available to other transactions. It
wouldn't make sense, would it?
Comparing MySQL and Oracle on this kind of test is "apples vs
oranges". Oracle, like InterBase, is a client/server system, designed to
provide concurrent a real-time views of the database state that are
particular to each user transaction. Freezing the database state in a
cache and dishing that up to other transactions is totally contradictory to
a consistent view.
If you don't care about a real-time view, implement a re-usable cache. If
you do, don't even go there.
heLen
>I think Jack was referring to resultset caching,InterBase does and always did cache resultsets. Pieces of resultsets get
>a feature present in the newer MySQL.
>Read somewhere about db benchmarks
>where MySQL performance "rivalled" Oracle simply
>because of this feature...
>
>Regards
>Kenneth
returned to the client in packets, the number of which is determined by the
client request. But the resultsets don't outlive the transaction in which
they are generated and they are not available to other transactions. It
wouldn't make sense, would it?
Comparing MySQL and Oracle on this kind of test is "apples vs
oranges". Oracle, like InterBase, is a client/server system, designed to
provide concurrent a real-time views of the database state that are
particular to each user transaction. Freezing the database state in a
cache and dishing that up to other transactions is totally contradictory to
a consistent view.
If you don't care about a real-time view, implement a re-usable cache. If
you do, don't even go there.
heLen