MIME-Version: 1.0
References: <CANzqJaD8o0UuK42F==BXZA=L380n=aXt+VJ93PN3waFbNhZHBg@mail.gmail.com>
 <2870091.1713739514@sss.pgh.pa.us>
In-Reply-To: <2870091.1713739514@sss.pgh.pa.us>
From: Ron Johnson <ronljohnsonjr@gmail.com>
Date: Sun, 21 Apr 2024 20:06:52 -0400
Message-ID: <CANzqJaAj9TRMKOwOv9pNjf7n5+e0bbd8ERZB2Zb8sdazVRmRwg@mail.gmail.com>
Subject: Re: CLUSTER vs. VACUUM FULL
To: pgsql-general <pgsql-general@postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000009f012c0616a437f0"
Archived-At: <https://www.postgresql.org/message-id/CANzqJaAj9TRMKOwOv9pNjf7n5%2Be0bbd8ERZB2Zb8sdazVRmRwg%40mail.gmail.com>
Precedence: bulk

--0000000000009f012c0616a437f0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Apr 21, 2024 at 6:45=E2=80=AFPM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Ron Johnson <ronljohnsonjr@gmail.com> writes:
> > Why is VACUUM FULL recommended for compressing a table, when CLUSTER do=
es
> > the same thing (similarly doubling disk space), and apparently runs jus=
t
> as
> > fast?
>
> CLUSTER makes the additional effort to sort the data per the ordering
> of the specified index.  I'm surprised that's not noticeable in your
> test case.
>

It's in a freshly restored database.  However, regular deletions of old
records, and normal vacuums would have led me to expect that the "fresh"
public.log would have been in relatively random order.

--0000000000009f012c0616a437f0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Sun, Apr 21, 2024 at 6:45=E2=80=AFPM T=
om Lane &lt;<a href=3D"mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>&gt; =
wrote:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex">Ron Johnson &lt;<a href=3D"mailto:ronljohnsonjr@gmail.com=
" target=3D"_blank">ronljohnsonjr@gmail.com</a>&gt; writes:<br>
&gt; Why is VACUUM FULL recommended for compressing a table, when CLUSTER d=
oes<br>
&gt; the same thing (similarly doubling disk space), and apparently runs ju=
st as<br>
&gt; fast?<br>
<br>
CLUSTER makes the additional effort to sort the data per the ordering<br>
of the specified index.=C2=A0 I&#39;m surprised that&#39;s not noticeable i=
n your<br>
test case.<br></blockquote><div><br></div><div>It&#39;s in a freshly restor=
ed database.=C2=A0 However, regular deletions of old records, and normal=C2=
=A0vacuums would have led me to expect that the &quot;fresh&quot; public.lo=
g would have been in relatively random order.</div><div><br></div></div></d=
iv>

--0000000000009f012c0616a437f0--