Re: Eliminating VACUUM FULL WAS: remove flatfiles.c
От | Alvaro Herrera |
---|---|
Тема | Re: Eliminating VACUUM FULL WAS: remove flatfiles.c |
Дата | |
Msg-id | 20090904204309.GM5603@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: Eliminating VACUUM FULL WAS: remove flatfiles.c (Dimitri Fontaine <dfontaine@hi-media.com>) |
Ответы |
Re: Eliminating VACUUM FULL WAS: remove flatfiles.c
|
Список | pgsql-hackers |
Dimitri Fontaine escribió: > Hi, > > Tom Lane <tgl@sss.pgh.pa.us> writes: > > Alvaro Herrera <alvherre@commandprompt.com> writes: > >> No problem, just CLUSTER that table same as today. > > > > Uh, no, that was Josh's point: you can't CLUSTER pg_class, because you > > can't change its relfilenode. If you do, backends won't know where to > > read pg_class to find out its relfilenode. > > Why can't MVCC apply here? You'd have two versions of the pg_class entry > that just has been CLUSTERed, and you keep the old relfilenode arround > too. MVCC applies, and you teach vacuum to clean out the old file when > cleaning out the no more visible tuple. It just doesn't work. pg_class (and various other rels) are special because they are needed to bootstrap the catalog system. See RelationCacheInitializePhase3. It wouldn't be possible to figure out what's pg_class relfilenode until you have read it from pg_class, which is precisely what we're trying to do. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
В списке pgsql-hackers по дате отправления: