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 === ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
