Re: Why do things slow down without a VACUUM?
От | GH |
---|---|
Тема | Re: Why do things slow down without a VACUUM? |
Дата | |
Msg-id | 20010429223859.C14349@over-yonder.net обсуждение исходный текст |
Ответ на | Re: Why do things slow down without a VACUUM? (Lincoln Yeoh <lyeoh@pop.jaring.my>) |
Ответы |
Re: Why do things slow down without a VACUUM?
|
Список | pgsql-general |
On Mon, Apr 30, 2001 at 11:23:57AM +0800, some SMTP stream spewed forth: > At 09:17 PM 29-04-2001 -0500, GH wrote: > > > >As it seems you know, PostgreSQL "leaves behind" the stagnant rows after > >an UPDATE or DELETE; it merely sets a flag (IIRC) to that effect. > > OK. I read http://www.ca.postgresql.org/docs/aw_pgsql_book/node110.html > > So the stagnant rows are for the other transactions. > > I was hoping that there would be a way for queries to find rows quickly, > ignoring stagnant rows. e.g. maybe a subindex pointing to the latest row > with some info so that transactions know whether they should use the latest > or not (Not valid if your transaction started before... - with the usual > rollover issues ;) ). Something like that anyway. You could probably talk to Alfred Perlstein about the work he did on this subject. Another thread is bickering about a patch that he (and others? who knows) developed. The availability of this patch is unknown to me, but its existence is certain. Good hunting. dan Say, wouldn't it sometimes be so much easier if everybody just shut the hell up and did something productive? People spend so much time fighting about stuff, and the root problem is left dangling amid the dust. *duck and cover* > > Cheerio, > Link.
В списке pgsql-general по дате отправления: