Re: CLUSTER details

Hello,

David G. Johnston wrote on 7. June 2024 15:24 (GMT +02:00):
> All of that is already covered on the page.

You are right, I missed the note about the two modes and their storage
consumption, I guess that part is described enough

> If you think it needs
> rewording I suggest you specify exactly what you think would be an
> improvement. For my part saying “rewrites the table contents into a new
> file” would probably be better than “physically reordered” which I
> sense

Exactly, something like that would help plus explicite mentioning
if any free pages (besides fillfactor) are created in the new files.

> you are misinterpreting as a kind of piecemeal operation when it isn’t.

Calm down, I am not (miss)interpreting anything I am asking for clarification
since it was unclear to me. Since I didnt want to assume how it works I could
not suggest a wordiing, without first relying on your expertise.

Is the following correct (I.e. it does not preserv free pages) and can
be added?

The temporary files for index and rewritten table occupy space on the same
filesystem as the original tablespace.
After successful completion,
all free pages of the clustered relation are deallocated.

Sidenote how is the feeling about pointing to
non-included extension? This footnote would be
an helpful tip:

If you need to carry out operations similar to CLUSTER or
VACCUUM FULL, but without blocking workload ("ONLINE"),
you might want to look into the pg_repack extension.
(And add sql-VACCUM to See Also)

Gruss
Bernd
--
http://bernd.eckenfels.net