Hi!
On Thu, Jun 14, 2018 at 5:37 AM Andres Freund <andres@anarazel.de> wrote:
> 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.
Yes, that could be useful.
> 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.
Makes sense for me.
> b) extensions containing AMs would need to do something INSERT ... ON
> CONFLICT DO NOTHING like.
We already have CREATE ACCESS METHOD command. I think this command
should handle that internally. And I don't understand why "ON
CONFLICT DO NOTHING". If AM with given name already exists in pg_am,
why should we ignore the error?
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
