Re: [HACKERS] UPDATE performance degradation (6.5.1)
От | Oleg Bartunov |
---|---|
Тема | Re: [HACKERS] UPDATE performance degradation (6.5.1) |
Дата | |
Msg-id | Pine.GSO.3.96.SK.990727191738.29708K-100000@ra обсуждение исходный текст |
Ответ на | Re: [HACKERS] UPDATE performance degradation (6.5.1) (Zeugswetter Andreas IZ5 <Andreas.Zeugswetter@telecom.at>) |
Список | pgsql-hackers |
On Tue, 27 Jul 1999, Zeugswetter Andreas IZ5 wrote: > Date: Tue, 27 Jul 1999 16:57:06 +0200 > From: Zeugswetter Andreas IZ5 <Andreas.Zeugswetter@telecom.at> > To: 'Oleg Bartunov' <oleg@sai.msu.su> > Cc: "'hackers@postgresql.org'" <hackers@postgresql.org> > Subject: Re: [HACKERS] UPDATE performance degradation (6.5.1) > > > > This is for table with one row after a lot of updates. > > Too much. vacuum analyze this table was a good medicine ! > > Is this a design problem ? > > > In PostgreSQL an update always adds a new row to the table. > The old rows get eliminated by vacuum that is the whole business of vacuum. > There has been some discussion for implementing row reuse, > but that is a major task. Ok, I understand now the size of the table. What's about index file ? Why it's so big. Look. just did delete from hits and vacuum analyze. om:/usr/local/pgsql/data/base/discovery$ l hits* -rw------- 1 postgres users 0 Jul 27 19:14 hits -rw------- 1 postgres users 2015232 Jul 27 19:14 hits_pkey after 6500 updates: om:/usr/local/pgsql/data/base/discovery$ l hits* -rw------- 1 postgres users 344064 Jul 27 19:23 hits -rw------- 1 postgres users 2097152 Jul 27 19:23 hits_pkey and it took a lot of time. Also I populate table hits by 10,000 rows and run the same test. It was incredibly slow. It seems index file doesn't affected by vacuum analyze ! Could we consider this as a bug ? Regards, Oleg > > Andreas > _____________________________________________________________ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
В списке pgsql-hackers по дате отправления: