On Thu, 5 Feb 2004, Edoardo Ceccarelli wrote: > BEFORE (copy of the db without having run the vacuum): > > explain analyze SELECT * FROM utente where luogorilasciodoc='ciao'; > QUERY PLAN > > -------------------------------------------------------------------------------------- > ---------------------- > Seq Scan on utente (cost=0.00..40947.90 rows=1826 width=724) (actual > time=131.17..856.96 rows=15 loops=1) > Filter: (luogorilasciodoc = 'ciao'::bpchar) > Total runtime: 857.06 msec > (3 rows) > > > AFTER (actual db) > portaportese=# explain analyze SELECT * FROM utente where luogorilasciodoc='ciao'; > QUERY PLAN > > -------------------------------------------------------------------------------------- > -------------------- > Seq Scan on utente (cost=0.00..92174.50 rows=3 width=724) (actual > time=705.41..6458.19 rows=15 loops=1) > Filter: (luogorilasciodoc = 'ciao'::bpchar) > Total runtime: 6458.29 msec > (3 rows > > Things are worst only for seqscan, when it uses indexscan timing is good.
Only thing I can think of is if storage method had been changed. Not sure if that would even affect it, or if it could do that by itself. Just brainstorming. -- Sam Barnett-Cormack Software Developer | Student of Physics & Maths UK Mirror Service (http://www.mirror.ac.uk) | Lancaster University ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
