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
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 |