Hackers,
While developing various Table Access Methods, I have wanted a callback for determining if CLUSTER (and VACUUM FULL)
shouldbe 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
errorfrom that callback is probably not too bad. For multi-relation cluster commands, that aborts the clustering of
otheryet to be processed relations, which doesn't seem acceptable. I tried fixing this with a ProcessUtility_hook, but
thatfires before the multi-relation cluster command has compiled the list of relations to cluster, meaning the
ProcessUtility_hookdoesn't have access to the necessary information. (It can be hacked to compile the list of
relationsitself, but that duplicates both code and effort, with the usual risks that the code will get out of sync.)
For my personal development, I have declared a new hook, bool (*relation_supports_cluster) (Relation rel). It gets
calledfrom commands/cluster.c in both the single-relation and multi-relation code paths, with warning or debug log
messagesoutput for relations that decline to be clustered, respectively.
Before posting a patch, do people think this sounds useful? Would you like the hook function signature to differ in
someway? Is a simple "yes this relation may be clustered" vs. "no this relation may not be clustered" interface overly
simplistic?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company