Re: Shared access methods? - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Shared access methods?
Date
Msg-id 20180614202306.c62jg4odwhivcwlr@alap3.anarazel.de
Whole thread Raw
In response to Re: Shared access methods?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Shared access methods?
List pgsql-hackers
On 2018-06-14 16:10:42 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Portability concerns over pq_sendbyte?
Next
From: Andres Freund
Date:
Subject: Re: Portability concerns over pq_sendbyte?