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 19:15:00
Message-ID: CALT9ZEFaG8UuGm-R-Vx_MMR+0_5wN+zwDCHbQ2NPxzdsEQq4DA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi, Alexander!

On Sun, 7 Apr 2024 at 12:34, Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com> wrote:

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

I made minor changes to the patch. Please find v11 attached.

Regards,
Pavel.

Attachment Content-Type Size
v11-0001-Custom-reloptions-for-table-AM.patch application/octet-stream 52.3 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-04-07 19:38:44 Re: EXCLUDE COLLATE in CREATE/ALTER TABLE document
Previous Message Andrey M. Borodin 2024-04-07 19:13:12 Re: MultiXact\SLRU buffers configuration