| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
| Cc: | "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 19:36:37 |
| Message-ID: | 17447.1252092997@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
I was wondering whether maintenance operations like "vacuum rewrite"
could get away with filling a new table file and then moving it into
place with rename(2), which is guaranteed atomic (at least on sane
filesystems). The idea doesn't work right off because (1) you need
to atomically install the updated indexes too, and (2) the table
might span more than one segment file. But maybe we could think of
something.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-09-04 20:01:00 | Re: Eliminating VACUUM FULL WAS: remove flatfiles.c |
| Previous Message | Alvaro Herrera | 2009-09-04 19:28:18 | Re: Eliminating VACUUM FULL WAS: remove flatfiles.c |