Re: Possible documentation error
От | Jim C. Nasby |
---|---|
Тема | Re: Possible documentation error |
Дата | |
Msg-id | 20061230200842.GQ71246@nasby.net обсуждение исходный текст |
Ответ на | Re: Possible documentation error (Martijn van Oosterhout <kleptog@svana.org>) |
Ответы |
Re: Possible documentation error
|
Список | pgsql-hackers |
On Tue, Dec 26, 2006 at 07:22:21PM +0100, Martijn van Oosterhout wrote: > On Tue, Dec 26, 2006 at 12:49:55PM -0500, D'Arcy J.M. Cain wrote: > > On Tue, 26 Dec 2006 18:12:45 +0100 > > Martijn van Oosterhout <kleptog@svana.org> wrote: > > > On Tue, Dec 26, 2006 at 12:04:40PM -0500, D'Arcy J.M. Cain wrote: > > > > Now it certainly seems to me that it should behave as described given > > > > the definition of VACUUM FULL so I am a little confused by my tests. > > > > My test table only has two entries in it. Is that the issue? In fact, > > > > I find the same behaviour if I do a simple VACUUM on the table. > > > > > > On a table with two entries, VACUUM FULL is going to do nothing of > > > interest. Moving tuples within a page is useless, generally. > > > > I thought that that might be the issue. The docs should probably say > > "can" instead of "will" then. > > The doumenttion is accurate as is. It says when "moved by VACUUM FULL". > In your case they wern't moved. If you change the word "will" to "can", > it will be wrong. Howso? There's no guarantee (which is what "will" implies) that a ctid will change on VACUUM FULL. In fact, your example demonstrates that; 0,1 stayed put. I'm sorry if it sounds like I'm picking nits, but using CTID to identify rows could provide a noticeable performance gain in some cases. But users can't make use of that if it's not clear exactly when and how CTIDs can change. -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
В списке pgsql-hackers по дате отправления: