From: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Shared access methods? |
Date: | 2018-06-14 12:59:22 |
Message-ID: | CAPpHfdti5v5Fc193b7ajABffDEM-wcp8jgt8GJrJ02vBvQ9aeg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi!
On Thu, Jun 14, 2018 at 5:37 AM Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2018-06-14 13:00:37 | Re: late binding of shared libs for C functions |
Previous Message | Robert Haas | 2018-06-14 12:44:58 | Re: WAL prefetch |