Re: Modest proposal to extend TableAM API for controlling cluster commands

> On Jun 15, 2022, at 8:50 PM, David G. Johnston <david.g.johnston@gmail.com> wrote:
>
> On Wed, Jun 15, 2022 at 8:18 PM Andres Freund <andres@anarazel.de> wrote:
> > If a simple callback like
> > relation_supports_cluster(Relation rel) is too simplistic
>
> Seems like it should be called: relation_supports_compaction[_by_removal_of_interspersed_dead_tuples]

Ok.

> Basically, if the user tells the table to make itself smaller on disk by removing dead tuples, should we support the case where the Table AM says: "Sorry, I cannot do that"?

I submit that's the only sane thing to do if the table AM already guarantees that the table will always be fully compacted.  There is no justification for forcing the table contents to be copied without benefit.

> If yes, then naming the table explicitly should elicit an error.  Having the table chosen implicitly should provoke a warning.  For ALTER TABLE CLUSTER there should be an error: which makes the implicit CLUSTER command a non-factor.

I'm basically fine with how you would design the TAM, but I'm going to argue again that the core project should not dictate these decisions.  The TAM's relation_supports_compaction() function can return true/false, or raise an error.  If raising an error is the right action, the TAM can do that. 

If the core code makes that decision, the TAM can't override, and that paints TAM authors into a corner.

How about a TAM that implements a write-once, read-many logic.  You get one multi-insert, and forever after you can't modify it (other than to drop the table, or perhaps to truncate it).

  That's a completely made-up-on-the-spot example, but it's not entirely without merit.

In what sense does this made-up TAM conflict with mvcc and wal?  It doesn't have all the features of heap, but that's not the same thing as violating mvcc or breaking wal.