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 01:55:04 |
Message-ID: | 20220616015504.yf5xhcfvipg23jpx@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2022-06-15 18:24:45 -0700, Mark Dilger wrote:
> > On Jun 15, 2022, at 6:01 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > On 2022-06-15 17:21:56 -0700, Mark Dilger wrote:
> >> While developing various Table Access Methods, I have wanted a callback for
> >> determining if CLUSTER (and VACUUM FULL) should be run against a table
> >> backed by a given TAM. The current API contains a callback for doing the
> >> guts of the cluster, but by that time, it's a bit too late to cleanly back
> >> out. For single relation cluster commands, raising an error from that
> >> callback is probably not too bad. For multi-relation cluster commands, that
> >> aborts the clustering of other yet to be processed relations, which doesn't
> >> seem acceptable.
> >
> > Why not? What else do you want to do in that case? Silently ignoring
> > non-clusterable tables doesn't seem right either. What's the use-case for
> > swallowing the error?
>
> Imagine you develop a TAM for which the concept of "clustering" doesn't have
> any defined meaning. Perhaps you've arranged the data in a way that has no
> similarity to heap, and now somebody runs a CLUSTER command (with no
> arguments.)
I think nothing would happen in this case - only pre-clustered tables get
clustered in an argumentless CLUSTER. What am I missing?
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Dilger | 2022-06-16 02:07:50 | Re: Modest proposal to extend TableAM API for controlling cluster commands |
Previous Message | Kyotaro Horiguchi | 2022-06-16 01:41:21 | Re: Using PQexecQuery in pipeline mode produces unexpected Close messages |