| From: | Marcos Pegoraro <marcos(at)f10(dot)com(dot)br> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | Ron Johnson <ronljohnsonjr(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: CLUSTER vs. VACUUM FULL |
| Date: | 2024-04-22 11:42:36 |
| Message-ID: | CAB-JLwYPrJpYGqsQFDpiMf6UFKeT1zwagabdb-2V3x0G8DqNPQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Em dom., 21 de abr. de 2024 às 22:35, David Rowley <dgrowleyml(at)gmail(dot)com>
escreveu:
>
> Both VACUUM FULL and CLUSTER go through a very similar code path. Both
> use cluster_rel(). VACUUM FULL just won't make use of an existing
> index to provide presorted input or perform a sort, whereas CLUSTER
> will attempt to choose the cheapest out of these two to get sorted
> results.
But wouldn't it be good that VACUUM FULL uses that index defined by
Cluster, if it exists ? Maybe an additional option for VACUUM FULL ?
Because if I periodically reorganize all tables I have to run CLUSTER once,
which will run on clustered tables, and VACUUM FULL on every table that is
not clustered, because if I run VACUUM FULL for entire database it'll just
ignore cluster index defined for every table. So, INDISCLUSTERED is used
when running CLUSTER but is ignored when running VACUUM FULL.
regards
Marcos
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nicolas Seinlet | 2024-04-22 11:50:27 | Re: Failing streaming replication on PostgreSQL 14 |
| Previous Message | Bagesh Kumar Singh | 2024-04-22 07:20:55 | Re: Not able to grant access on pg_signal_backend on azure flexible server |