Re: Table AM Interface Enhancements

From: Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>
To: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, Japin Li <japinli(at)hotmail(dot)com>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Table AM Interface Enhancements
Date: 2024-04-07 08:34:42
Message-ID: CALT9ZEEx-zFcRseeaHZCFt8H+TdiyrJ70JUa6y7jYxau1O01Kg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi, Alexander!

On Sun, 7 Apr 2024 at 07:33, Alexander Korotkov <aekorotkov(at)gmail(dot)com>
wrote:

> Hi, Pavel!
>
> On Fri, Apr 5, 2024 at 6:58 PM Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>
> wrote:
> > On Tue, 2 Apr 2024 at 19:17, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> >>
> >> On Tue, 2024-04-02 at 11:49 +0300, Alexander Korotkov wrote:
> >> > I don't like the idea that every custom table AM reltoptions should
> >> > begin with StdRdOptions. I would rather introduce the new data
> >> > structure with table options, which need to be accessed outside of
> >> > table AM. Then reloptions will be a backbox only directly used in
> >> > table AM, while table AM has a freedom on what to store in reloptions
> >> > and how to calculate externally-visible options. What do you think?
> >>
> >> Hi Alexander!
> >>
> >> I agree with all of that. It will take some refactoring to get there,
> >> though.
> >>
> >> One idea is to store StdRdOptions like normal, but if an unrecognized
> >> option is found, ask the table AM if it understands the option. In that
> >> case I think we'd just use a different field in pg_class so that it can
> >> use whatever format it wants to represent its options.
> >>
> >> Regards,
> >> Jeff Davis
> >
> > I tried to rework a patch regarding table am according to the input from
> Alexander and Jeff.
> >
> > It splits table reloptions into two categories:
> > - common for all tables (stored in a fixed size structure and could be
> accessed from outside)
> > - table-am specific (variable size, parsed and accessed by access method
> only)
>
> Thank you for your work. Please, check the revised patch.
>
> It makes CommonRdOptions a separate data structure, not directly
> involved in parsing the reloption. Instead table AM can fill it on
> the base of its reloptions or calculate the other way. Patch comes
> with a test module, which comes with heap-based table AM. This table
> AM has "enable_parallel" reloption, which is used as the base to set
> the value of CommonRdOptions.parallel_workers.
>
To me, a patch v10 looks good.

I think the comment for RelationData now applies only to rd_options, not
to rd_common_options.
>NULLs means "use defaults".

Regards,
Pavel

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2024-04-07 09:33:52 Re: Flushing large data immediately in pqcomm
Previous Message Nazir Bilal Yavuz 2024-04-07 08:26:34 Re: Change prefetch and read strategies to use range in pg_prewarm ... and raise a question about posix_fadvise WILLNEED