| From: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, daveg(at)sonic(dot)net, Andrew Dunstan <andrew(at)dunslane(dot)net>, Greg Stark <gsstark(at)mit(dot)edu>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Eliminating VACUUM FULL WAS: remove flatfiles.c |
| Date: | 2009-09-04 20:37:39 |
| Message-ID: | m21vmm1m5o.fsf@hi-media.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Alvaro Herrera <alvherre(at)commandprompt(dot)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.
Or you take necessary locks to protect the operation.
Something so obvious that I'll regret asking why it can not be done this
way sure will get back from this mail :)
Regards.
--
dim
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2009-09-04 20:43:09 | Re: Eliminating VACUUM FULL WAS: remove flatfiles.c |
| Previous Message | Grzegorz Jaskiewicz | 2009-09-04 20:29:42 | Re: clang's static checker report. |