From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, 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 20:23:06 |
Message-ID: | 20180614202306.c62jg4odwhivcwlr@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2018-06-14 16:10:42 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2018-06-14 15:59:22 +0300, Alexander Korotkov wrote:
> >> 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?
>
> > Well, right now an AM containing extension creates things in each
> > database (i.e. same scope as extensions). But with shared AMs that
> > wouldn't be the case - you might still want to create the extension in
> > another database. So we'd need to have CREATE ACCESS METHOD check
> > whether already is the same entry, and only delete it on DROP ACCESS
> > METHOD if there's no dependencies from other databases...
>
> I'm not really buying this idea at all, at least not for index AMs,
> because you also need a pile of other database-local infrastructure
> --- opclasses, operators, functions, etc. Trying to make pieces of
> that be shared is not going to end well.
Yea, I do think there's a number of issues around exactly that - in fact
I raised them when Robert was talking about the issue before.
But I do think there's a few things that are doable without actually
needing to invoke any user defined code aside of the AM code
itself. E.g. heap pruning / aggressively setting hint bits doesn't need
to invoke operators, and I can think of some ways to implement index
delete marking that does so without invoking any comparators either.
Thus it seems like this'd still allow to implement quite a bit of new
useful infrastructure, even though more would be needed.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-06-14 20:25:30 | Re: Portability concerns over pq_sendbyte? |
Previous Message | Tom Lane | 2018-06-14 20:17:28 | Re: Portability concerns over pq_sendbyte? |