Re: Modest proposal to extend TableAM API for controlling cluster commands
От | Andres Freund |
---|---|
Тема | Re: Modest proposal to extend TableAM API for controlling cluster commands |
Дата | |
Msg-id | 20220616015504.yf5xhcfvipg23jpx@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Modest proposal to extend TableAM API for controlling cluster commands (Mark Dilger <mark.dilger@enterprisedb.com>) |
Ответы |
Re: Modest proposal to extend TableAM API for controlling cluster commands
|
Список | 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@anarazel.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
В списке pgsql-hackers по дате отправления: