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
casewhere 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
dictatethese decisions.  The TAM's relation_supports_compaction() function can return true/false, or raise an error.
Ifraising 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. 

> However, given that should the table structure change it is imperative that the Table AM be capable of producing a
newphysical relation with the correct data, which will have been compacted as a side-effect, it seems like, explicit or
implicit,expecting any Table AM to do that when faced with Vacuum Full is reasonable.  Which leaves deciding how to
allowa table with a given TAM to prevent itself from being added to the CLUSTER roster.  And decide whether an opt-out
featurefor implicit VACUUM FULL is something we should offer as well. 
>
> I'm doubtful that a TAM that is pluggable into the MVCC and WAL architecture of PostgreSQL could avoid this basic
contractbetween the system and its users. 

How about a TAM that implements a write-once, read-many logic.  You get one multi-insert, and forever after you can't
modifyit (other than to drop the table, or perhaps to truncate it).  That's a completely made-up-on-the-spot example,
butit's not entirely without merit.  You could avoid a lot of locking overhead when using such a table, since you'd
knowa priori that nobody else is modifying it.  It could also be implemented with a smaller tuple header, since a lot
ofthe header bytes in heap tuples are dedicated to tracking updates.  You wouldn't need a per-row inserting
transaction-Ideither, since you could just store one per table, knowing that all the rows were inserted in the same
transaction.

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
notthe same thing as violating mvcc or breaking wal. 

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company