Re: WIP: Rework access method interface

From: Petr Jelinek <petr(at)2ndquadrant(dot)com>
To: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: WIP: Rework access method interface
Date: 2015-08-10 10:12:10
Message-ID: 55C878FA.8060201@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2015-08-10 10:50:42 Re: Commitfest remaining "Needs Review" items
Previous Message David Rowley 2015-08-10 09:27:11 Re: Moving SS_finalize_plan processing to the end of planning