> On Jun 16, 2022, at 12:28 AM, David G. Johnston <david.g.johnston@gmail.com> wrote:
>
> But you are basically proposing a reworking of the existing system into one that makes pretty much any SQL Command
somethingthat a TAM can treat as being an optional request by the user;
Yes, and I think I'm perfectly correct in asking for that. If the standard you are proposing (albeit as Devil's
Advocate)were applied to filesystems, nobody could ever implement /dev/null, on the argument that users have a
reasonableexpectation that data they write to a file will be there for them to read later. Yet Michael Paquier wrote a
blackholeTAM, and although I don't find it terribly useful, I do think it's a reasonable thing for somebody to be able
towrite.
> whereas today the system presumes that the implementations will respond to these commands.
That depends on what you mean by "respond to". A TAM which implements a tamper resistant audit log responds to update
anddelete commands with a "permission denied" error. A TAM which implements running aggregates implements insert
commandsby computing and inserting a new running aggregate value and reclaiming space from old running aggregate values
whenno transaction could any longer see them. You can do this stuff at a higher level with hooks, functions, triggers,
andrules, inserting into a heap, and having to periodically vacuum, by why would you want to? That's almost guaranteed
tobe slower, maybe even orders of magnitude slower.
> And to make this change without any core code having such a need.
The core code won't have any such need, because the core code is content with heap, and the API already accommodates
heap. It seems Andres moved the project in the direction of allowing custom TAMs when he created the Table AM
interface,and I'm quite pleased that he did so, but it doesn't allow nearly enough flexibility to do all the
interestingthings a TAM could otherwise do. Consider for example that the multi_insert hook uses a BulkInsertStateData
parameter,defined as:
typedef struct BulkInsertStateData
{
BufferAccessStrategy strategy; /* our BULKWRITE strategy object */
Buffer current_buf; /* current insertion target page */
} BulkInsertStateData;
which is just the structure heap would want, but what about a TAM that wants to route different tuples to different
pages? The "current_buf" isn't enough information, and there's no void *extra field, so you're just sunk.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company