On 4/22/24 11:45 AM, Ron Johnson wrote:
On Mon, Apr 22, 2024 at 12:29 PM David G. Johnston
<david.g.johnston@xxxxxxxxx <mailto:david.g.johnston@xxxxxxxxx>> wrote:
On Mon, Apr 22, 2024, 08:37 Ron Johnson <ronljohnsonjr@xxxxxxxxx
<mailto:ronljohnsonjr@xxxxxxxxx>> wrote:
On Mon, Apr 22, 2024 at 10:25 AM Tom Lane <tgl@xxxxxxxxxxxxx
<mailto:tgl@xxxxxxxxxxxxx>> wrote:
Marcos Pegoraro <marcos@xxxxxxxxxx
<mailto:marcos@xxxxxxxxxx>> writes:
> But wouldn't it be good that VACUUM FULL uses that index
defined by
> Cluster, if it exists ?
No ... what would be the difference then?
What the VACUUM docs "should" do, it seems, is suggest CLUSTER
on the PK, if the PK is a sequence (whether that be an actual
sequence, or a timestamp or something else that grows
monotonically).
That's because the data is already roughly in PK order.
If things are bad enough to require a vacuum full that doesn't seem
like a good assumption.
Sure it does.
For example, I just deleted the oldest half of the records in 30
tables. Tables who's CREATED_ON timestamp value strongly correlates to
the synthetic PK sequence values.
Thus, the remaining records were still mostly in PK order. CLUSTERs on
the PK values would have taken just about as much time as the VACUUM
FULL statements which I /did/ run.
1) If they are already in enough of a PK order that the CLUSTER time vs
VACUUM FULL time would not be material as there is not much or any
sorting to do then what does the CLUSTER gain you? Unless this table
then became read only whatever small gain arose from the CLUSTER would
fade away as UPDATEs and DELETEs where done.
2) What evidence is there that the records where still in PK order just
because you deleted based on CREATED_ON? I understand the correlation
between CREATED_ON and the PK just not sure why that would necessarily
translate to an on disk order by PK?
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
