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:30:04 |
Message-ID: | 20220616023004.njo7kyrib26buw77@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2022-06-15 19:21:42 -0700, Mark Dilger wrote:
> > On Jun 15, 2022, at 7:14 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > 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?
>
> It's effectively a synonym which determines whether the "bool use_sort"
> parameter of the table AM's relation_copy_for_cluster will be set. Heap-AM
> plays along and sorts or not based on that.
Hardly a synonym if it behaves differently?
> But it's up to the TAM what it wants to do with that boolean, if in fact it
> does anything at all based on that. A TAM could decide to do the exact
> opposite of what Heap-AM does and instead sort on VACUUM FULL but not sort
> on CLUSTER, or perhaps perform a randomized shuffle, or <insert your weird
> behavior here>.
That's bogus. Yes, an AM can do stupid stuff in a callback. But so what,
that's possible with all extension APIs.
> From the point-of-view of a TAM implementor, VACUUM FULL and CLUSTER are
> synonyms. Or am I missing something?
The callback gets passed use_sort. So just implement it use_sort = false and
error out if use_sort = true?
> >> , 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.
>
> Perhaps they want to give the TAM information about which index to use for
> sorting, on those occasions when the TAM's logic dictates that sorting is
> appropriate, but not in response to a cluster command.
I have little sympathy to randomly misusing catalog contents and then
complaining that those catalog contents have an effect.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2022-06-16 03:07:03 | Re: fix stats_fetch_consistency value in postgresql.conf.sample |
Previous Message | Mark Dilger | 2022-06-16 02:24:59 | Re: Modest proposal to extend TableAM API for controlling cluster commands |