Hi, Forewords: re-reading, I hope my english will not make this sound like a high-kick when I'm just struggling to understand what all this is about. Sending in order not to regret missing the oportunity I think I'm seeing...
Tom Lane <t...@sss.pgh.pa.us> writes: > Hannu Krosing <ha...@2ndquadrant.com> writes: >> On Wed, 2009-09-16 at 21:19 -0400, Tom Lane wrote: >>> VACUUM FULL CONCURRENTLY is a contradiction in terms. Wishing it were >>> possible doesn't make it so. > >> It depends on what do you mean by "VACUUM FULL" > > Anything that moves tuples is not acceptable as a hidden background > operation, because it will break applications that depend on CTID. I though this community had the habit of pushing public interface backward compatibility while going as far as requiring systematic full dump and restore cycle for major version upgrade in order to allow for internal redesign anytime in development. And even if it's easy enough to SELECT ctid FROM table, this has always been an implementation detail in my mind, the same way catalog layout is. I don't see any reason why not breaking the user visible behavior of tuples CTID between any two major releases, all the more when the reason we're talking about it is automated online physical optimisations, which seems to be opening the door for bloat resistant PostgreSQL. > The utility Heikki is talking about is something that DBAs would > invoke explicitly, presumably with an understanding of the side effects. That's the CLUSTER on seqscan. As far as the table rewritting goes, the above only states your POV, based on ctid backward compatibility need which I'm not the only one here not sharing, let alone understanding. Am I completely wet here? -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers