| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Modest proposal to extend TableAM API for controlling cluster commands |
| Date: | 2022-06-16 02:14:21 |
| Message-ID: | 20220616021421.mqljbe6ygaon4mni@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2022-06-15 19:07:50 -0700, Mark Dilger wrote:
> > On Jun 15, 2022, at 6:55 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> >
> > I think nothing would happen in this case - only pre-clustered tables get
> > clustered in an argumentless CLUSTER. What am I missing?
>
> The "VACUUM FULL" synonym of "CLUSTER" doesn't depend on whether the target
> is pre-clustered
VACUUM FULL isn't a synonym of CLUSTER. While a good bit of the implementation
is shared, VACUUM FULL doesn't order the table contents. I see now reason why
an AM shouldn't support VACUUM FULL?
> , and both will run against the table if the user has run an ALTER
> TABLE..CLUSTER ON.
If a user does that for a table that doesn't support clustering, well, I don't
see what's gained by not erroring out.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Dilger | 2022-06-16 02:21:42 | Re: Modest proposal to extend TableAM API for controlling cluster commands |
| Previous Message | Mark Dilger | 2022-06-16 02:07:50 | Re: Modest proposal to extend TableAM API for controlling cluster commands |