Hi,
Several features in various discussed access methods would benefit from
being able to perform actions when writing out a buffer. As an example,
because it doesn't require understanding any of the new proposed storage
formats, it'd be good for performance if we could eagerly set hint bits
/ perform page level pruning when cleaning a dirty buffer either during
checkpoint writeout or bgwriter / backend reclaim. That'd allow to
avoid the write amplification issues in several of current and proposed
cleanup schemes.
Unfortunately that's currently not really easy to do. Buffers don't
currently know which AM they belong to, therefore we can't know how to
treat it at writeout time. It's not that hard to make space in the
buffer descriptor to additionally store the oid of the associated AM,
e.g. we could just replace buf_id with a small bit of pointer math.
But even if we had a AM oid, it'd be unclear what to do with it as it'd
be specific to a database. Which makes it pretty much useless for tasks
happening on writeout of victim buffers / checkpoint.
Thus I think it'd be better design to have pg_am be a shared
relation. That'd imply a two things:
a) amhandler couldn't be regproc but would need to be two fields, one
pointing to internal or a shlib, the other to the function name.
b) extensions containing AMs would need to do something INSERT ... ON
CONFLICT DO NOTHING like.
I don't think this is the most urgent feature for making pluggable AMs
useful, but given that we're likely going to whack around pg_am, and
that pg_am is fairly new in its current incarnation, it seems like a
good idea to discuss this now.
Comments?
Greetings,
Andres Freund
PS: I could have written more on this, but people are urging me to come
to dinner, so thank them ;)
