On Wed, 2002-02-27 at 05:23, Neil Conway wrote:
> On Tue, 2002-02-26 at 19:08, Dann Corbit wrote:
> > Statistical tools are a good idea, because they can tell us where
> > indexes should be added. However, you cannot simply return the result
> > of the previous query, because the contents may have changed since the
> > last time it was executed. It is simply invalid to do that. If some
> > other system is doing that, then it isn't a relational database.
>
> No -- as I said, any inserts, updates or deletes that affect the table
> in question will cause a full cache flush.
>
> > How do you know whether or not someone has affected the row that you
> > are reading? If you do not know, then every single update, insert or
> > delete will mean that you have to refresh.
>
> Yes, that is true.
>
> > And not only that, you will
> > also have to track it. For sure, it will make the whole system run
> > more slowly rather than faster.
>
> I don't think tracking changes imposes a lot of overhead -- it is
> relatively simple to determine if a query affects a given table.
Perhaps you can do it in a simple way for MySQL which has no
rules/triggers/foreign keys with ON DELETE CASCADE.
The only way I can think of is by putting some kind of rule or trigger
on the table affected.
>
> Hmmm... the more I think about it, the more unusual it would be for
> _exactly_ the same query to be repeated a lot. However, the article
> reported a significant performance gain when this feature was enabled.
> That could mean that:
>
> (a) the performance measurements/benchmarks used by the article were
> synthetic and don't reflect real database applications
I think that a Slashdot-type web application would probably benefit a
lot.
----------------
Hannu
