am 22.08.2005, um 22:13:49 +0200 mailte Ben-Nes Yonatan folgendes:
> I think that I was misunderstood, Ill make an example:
Okay:
> Lets say that im making the following query for the first time on the
> "motorcycles" table which got an index on the "manufacturer" field:
>
> EXPLAIN ANALYZE SELECT manufacturer FROM motorcycles WHERE
> manufacturer='suzuki';
> .. Total runtime: 3139.587 ms
neither the DB nor the OS has the the table and index in the cache.
>
> Now im doing the same query again and i get a much faster result (cause of
> the "caching"): Total runtime: 332.53 ms
OS and DN has now the table and index in the cache.
>
> After both of those queries I drop the index and query the table again with
> the exact same query as before and now I receive: Total runtime: 216834.871
> ms
Without index -> DB make a seq-scan. Very slow, of cource.
>
> And for my last check I run the exact same query again (without creating
> the INDEX back again) and I get quite similar result to my third query:
> Total runtime: 209218.01 ms
Never mind. The table is too big for the cache.
> My problem is that (maybe I just dont understand something basic here...)
> the last 2 (also the second query but I dont care about that) queries were
> using the "cache" that was created after the first query (which had an
> INDEX) so none of them actually showed me what will happen if a client will
> do such a search (without an INDEX) for the first time.
>
> I want to delete that "caching" after I do the first 2 queries so my next
> queries will show me "real life results".
No problem: demount all RAM and send this to me ;-)
Regards, Andreas
--
Andreas Kretschmer (Kontakt: siehe Header)
Heynitz: 035242/47212, D1: 0160/7141639
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
=== Schollglas Unternehmensgruppe ===
