Re: WIP: Rework access method interface - Mailing list pgsql-hackers

From Petr Jelinek
Subject Re: WIP: Rework access method interface
Date
Msg-id 55C878FA.8060201@2ndquadrant.com
Whole thread Raw
In response to WIP: Rework access method interface  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Responses Re: WIP: Rework access method interface  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
List pgsql-hackers
On 2015-08-09 23:56, Alexander Korotkov wrote:
> Hacker,
>
> some time before I proposed patches implementing CREATE ACCESS METHOD.
> http://www.postgresql.org/message-id/CAPpHfdsXwZmojm6Dx+TJnpYk27kT4o7Ri6X_4OSWcByu1Rm+VA@mail.gmail.com
> As I get from comments to my patches and also from Tom's comment about
> AM interface in tablesampling thread – AM interface needs reworking. And
> AFAICS AM interface rework is essential to have CREATE ACCESS METHOD
> command.
> http://www.postgresql.org/message-id/5438.1436740611@sss.pgh.pa.us

Cool, I was planning to take a stab at this myself when I have time, so 
I am glad you posted this.

> This is why I'd like to show a WIP patch implementing AM interface
> rework. Patch is quite dirty yet, but I think it illustrated the idea
> quite clear. AM now have single parameter – handler function. This
> handler returns pointer to AmRoutine which have the same data as pg_am
> had before. Thus, API is organized very like FDW.
>

I wonder if it would make sense to call it IndexAmRoutine instead in 
case we add other AMs (like the sequence am, or maybe column store if 
that's done as AM) in the future.

The patch should probably add the am_handler type which should be return 
type of the am handler function (see fdw_handler and tsm_handler types).

I also think that the CHECK_PROCEDUREs should be in the place of the 
original GET_REL_PROCEDUREs  (just after relation check). If the 
interface must exist we may as well check for it at the beginning and 
not after we did some other work which is useless without the interface.

> However, this patch appears to take more work than I expected. It have
> to do many changes spread among many files.

Yeah you need to change the definition and I/O handling of every AM 
function, but that's to be expected.

> Also, it appears not so easy
> to hide amsupport into AmRoutine, because it's needed for relcache. As a
> temporary solution it's duplicated in RelationData.
>

I don't understand this, there is already AmRoutine in RelationData, why 
the need for additional field for just amsupport?

--  Petr Jelinek                  http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Moving SS_finalize_plan processing to the end of planning
Next
From: Etsuro Fujita
Date:
Subject: Re: Commitfest remaining "Needs Review" items