Re: UPDATE slow
От | Nigel J. Andrews |
---|---|
Тема | Re: UPDATE slow |
Дата | |
Msg-id | Pine.LNX.4.21.0302050028330.20150-100000@ponder.fairway2k.co.uk обсуждение исходный текст |
Ответ на | Re: UPDATE slow (Stephan Szabo <sszabo@megazone23.bigpanda.com>) |
Ответы |
Re: UPDATE slow
|
Список | pgsql-general |
On Tue, 4 Feb 2003, Stephan Szabo wrote: > On Tue, 4 Feb 2003, John Smith wrote: > > > That works - updates on foo take about 1.4 seconds. I dropped all the > > indexes and fk's on stats and updates there take about 2.8 seconds. > > These are on the cygwin machine. > > The 2.8 seconds is on stats after dropping the fks and indexes? But > it didn't help on the linux box? > I tried this earlier on just a plain: create table testme ( id integer unique, clicks integer unique ); This is my explain: desticorp=> explain analyze select count(1) from testme; NOTICE: QUERY PLAN: Aggregate (cost=22.50..22.50 rows=1 width=0) (actual time=78.52..78.52 rows=1 loops=1) -> Seq Scan on testme (cost=0.00..20.00 rows=1000 width=0) (actual time=0.11..51.74 rows=11999 loops=1) Total runtime: 78.67 msec EXPLAIN desticorp=> explain analyze update testme set clicks = clicks + 123; NOTICE: QUERY PLAN: Seq Scan on testme (cost=0.00..20.00 rows=1000 width=14) (actual time=0.03..256.21 rows=11999 loops=1) Total runtime: 2060.41 msec EXPLAIN As you can see this took 2 seconds after already been given the chance to cache the table. It's also possible to see that I used 12000 rows in my table and that the sequential scan part of the operation is a helluva lot slower when writing. This is on a dual P-III 550MHz system. Memory settings probably aren't tuned too much though I don't think that would impact too much on this quick test. Although loaded and usually noticable delays in window refresh when flicking through my screens this system seems to have a very low CPU utilisation and plenty of memory usable (for a change). Although I am wondering what I've run in the last couple of weeks that's pushed me to use 150MB of swap (768MB physical so not an insignificant amount). Therefore John's 2.8s seems a reasonable time to me. -- Nigel J. Andrews
В списке pgsql-general по дате отправления: