Hi, Pavel!
On Fri, Apr 5, 2024 at 6:58 PM Pavel Borisov <pashkin.elfe@gmail.com> wrote:
> On Tue, 2 Apr 2024 at 19:17, Jeff Davis <pgsql@j-davis.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.
------
Regards,
Alexander Korotkov