Re: R: slow seqscan after vacuum analize
От | Sam Barnett-Cormack |
---|---|
Тема | Re: R: slow seqscan after vacuum analize |
Дата | |
Msg-id | Pine.LNX.4.50.0402050055510.13707-100000@short.lancs.ac.uk обсуждение исходный текст |
Ответ на | R: slow seqscan after vacuum analize ("Edoardo Ceccarelli" <eddy@axa.it>) |
Ответы |
R: R: slow seqscan after vacuum analize
R: R: slow seqscan after vacuum analize |
Список | pgsql-admin |
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
В списке pgsql-admin по дате отправления: