Horton

Thread

  1. Allow table AMs to define their own reloptions

    Julien Tachoires <julien@tachoires.me> — 2025-03-02T08:56:41Z

    Hi,

With the help of the new TAM routine 'relation_options', table access 
methods can with this patch define their own reloptions 
parser/validator.

These reloptions can be set via the following commands:
1. CREATE TABLE ... USING table_am
       WITH (option1='value1', option2='value2');
2. ALTER TABLE ...
       SET (option1 'value1', option2 'value2');
3. ALTER TABLE ... SET ACCESS METHOD table_am
       OPTIONS (option1 'value1', option2 'value2');

When changing table's access method, the settings inherited from the 
former TAM can be dropped (if not supported by the new TAM) via: DROP 
option, or, updated via: SET option 'value'.

Currently, tables using different TAMs than heap are able to use heap's 
reloptions (fillfactor, toast_tuple_target, etc...). With this patch 
applied, this is not the case anymore: if the TAM needs to have access 
to similar settings to heap ones, they have to explicitly define them.

The 2nd patch file includes a new test module 'dummy_table_am' which 
implements a dummy table access method utilized to exercise TAM 
reloptions. This test module is strongly based on what we already have 
in 'dummy_index_am'. 'dummy_table_am' provides a complete example of TAM 
reloptions definition.

This work is directly derived from SadhuPrasad's patch here [2]. Others 
attempts were posted here [1] and here [3].

[1] https://www.postgresql.org/message-id/flat/429fb58fa3218221bb17c7bf9e70e1aa6cfc6b5d.camel%40j-davis.com
[2] https://www.postgresql.org/message-id/flat/CAFF0-CG4KZHdtYHMsonWiXNzj16gWZpduXAn8yF7pDDub+GQMg@mail.gmail.com
[3] https://www.postgresql.org/message-id/flat/AMUA1wBBBxfc3tKRLLdU64rb.1.1683276279979.Hmail.wuhao%40hashdata.cn

-- 
Julien Tachoires

  2. Re: Allow table AMs to define their own reloptions

    Julien Tachoires <julien@tachoires.me> — 2025-03-02T13:23:54Z

    On Sun, Mar 02, 2025 at 09:56:41AM +0100, Julien Tachoires wrote:
> With the help of the new TAM routine 'relation_options', table access 
> methods can with this patch define their own reloptions 
> parser/validator.
> 
> These reloptions can be set via the following commands:
> 1. CREATE TABLE ... USING table_am
>        WITH (option1='value1', option2='value2');
> 2. ALTER TABLE ...
>        SET (option1 'value1', option2 'value2');
> 3. ALTER TABLE ... SET ACCESS METHOD table_am
>        OPTIONS (option1 'value1', option2 'value2');
> 
> When changing table's access method, the settings inherited from the 
> former TAM can be dropped (if not supported by the new TAM) via: DROP 
> option, or, updated via: SET option 'value'.
> 
> Currently, tables using different TAMs than heap are able to use heap's 
> reloptions (fillfactor, toast_tuple_target, etc...). With this patch 
> applied, this is not the case anymore: if the TAM needs to have access 
> to similar settings to heap ones, they have to explicitly define them.
> 
> The 2nd patch file includes a new test module 'dummy_table_am' which 
> implements a dummy table access method utilized to exercise TAM 
> reloptions. This test module is strongly based on what we already have 
> in 'dummy_index_am'. 'dummy_table_am' provides a complete example of TAM 
> reloptions definition.
> 
> This work is directly derived from SadhuPrasad's patch here [2]. Others 
> attempts were posted here [1] and here [3].
> 
> [1] https://www.postgresql.org/message-id/flat/429fb58fa3218221bb17c7bf9e70e1aa6cfc6b5d.camel%40j-davis.com
> [2] https://www.postgresql.org/message-id/flat/CAFF0-CG4KZHdtYHMsonWiXNzj16gWZpduXAn8yF7pDDub+GQMg@mail.gmail.com
> [3] https://www.postgresql.org/message-id/flat/AMUA1wBBBxfc3tKRLLdU64rb.1.1683276279979.Hmail.wuhao%40hashdata.cn

Please find a new version including minor fixes: 'TAM' terms are
replaced by 'table AM'

-- 
Julien Tachoires

  3. Re: Allow table AMs to define their own reloptions

    Yura Sokolov <y.sokolov@postgrespro.ru> — 2025-03-02T15:20:07Z

    02.03.2025 16:23, Julien Tachoires пишет:
> On Sun, Mar 02, 2025 at 09:56:41AM +0100, Julien Tachoires wrote:
>> With the help of the new TAM routine 'relation_options', table access 
>> methods can with this patch define their own reloptions 
>> parser/validator.
>>
>> These reloptions can be set via the following commands:
>> 1. CREATE TABLE ... USING table_am
>>        WITH (option1='value1', option2='value2');
>> 2. ALTER TABLE ...
>>        SET (option1 'value1', option2 'value2');
>> 3. ALTER TABLE ... SET ACCESS METHOD table_am
>>        OPTIONS (option1 'value1', option2 'value2');
>>
>> When changing table's access method, the settings inherited from the 
>> former TAM can be dropped (if not supported by the new TAM) via: DROP 
>> option, or, updated via: SET option 'value'.
>>
>> Currently, tables using different TAMs than heap are able to use heap's 
>> reloptions (fillfactor, toast_tuple_target, etc...). With this patch 
>> applied, this is not the case anymore: if the TAM needs to have access 
>> to similar settings to heap ones, they have to explicitly define them.
>>
>> The 2nd patch file includes a new test module 'dummy_table_am' which 
>> implements a dummy table access method utilized to exercise TAM 
>> reloptions. This test module is strongly based on what we already have 
>> in 'dummy_index_am'. 'dummy_table_am' provides a complete example of TAM 
>> reloptions definition.
>>
>> This work is directly derived from SadhuPrasad's patch here [2]. Others 
>> attempts were posted here [1] and here [3].
>>
>> [1] https://www.postgresql.org/message-id/flat/429fb58fa3218221bb17c7bf9e70e1aa6cfc6b5d.camel%40j-davis.com
>> [2] https://www.postgresql.org/message-id/flat/CAFF0-CG4KZHdtYHMsonWiXNzj16gWZpduXAn8yF7pDDub+GQMg@mail.gmail.com
>> [3] https://www.postgresql.org/message-id/flat/AMUA1wBBBxfc3tKRLLdU64rb.1.1683276279979.Hmail.wuhao%40hashdata.cn
> 
> Please find a new version including minor fixes: 'TAM' terms are
> replaced by 'table AM'

Good day, Julien.

Your forgot another one attempt discussion with patch [1] with alive
commitfest entry [2]

[1] https://postgr.es/m/flat/3766675.7eaCOWfIcx%40thinkpad-pgpro
[2] https://commitfest.postgresql.org/patch/4688/


-------
regards
Yura Sokolov aka funny-falcon

  4. Re: Allow table AMs to define their own reloptions

    Julien Tachoires <julien@tachoires.me> — 2025-03-04T06:16:19Z

    Hi Yura,

On Sun, Mar 02, 2025 at 06:20:07PM +0300, Yura Sokolov wrote:
> Your forgot another one attempt discussion with patch [1] with alive
> commitfest entry [2]
> 
> [1] https://postgr.es/m/flat/3766675.7eaCOWfIcx%40thinkpad-pgpro
> [2] https://commitfest.postgresql.org/patch/4688/

Thank you. After taking a look at the patch itself and the email thread,
it seems this patch does not add custom reloptions to table AMs, see
[1].

[1]: https://www.postgresql.org/message-id/1823308.yXV3o4JbTB%40thinkpad-pgpro

-- 
Julien Tachoires

  5. Re: Allow table AMs to define their own reloptions

    Yura Sokolov <y.sokolov@postgrespro.ru> — 2025-03-04T09:19:53Z

    04.03.2025 09:16, Julien Tachoires пишет:
> Hi Yura,
> 
> On Sun, Mar 02, 2025 at 06:20:07PM +0300, Yura Sokolov wrote:
>> Your forgot another one attempt discussion with patch [1] with alive
>> commitfest entry [2]
>>
>> [1] https://postgr.es/m/flat/3766675.7eaCOWfIcx%40thinkpad-pgpro
>> [2] https://commitfest.postgresql.org/patch/4688/
> 
> Thank you. After taking a look at the patch itself and the email thread,
> it seems this patch does not add custom reloptions to table AMs, see
> [1].
> 
> [1]: https://www.postgresql.org/message-id/1823308.yXV3o4JbTB%40thinkpad-pgpro

But intention of this patch is to make adding options easier, as author says:

  But new option engine will make adding custom options for table AM more
  easy task, as main goal of this patch is to  simplify adding options
  everywhere they needed. And yes, adding custom table AM options is one of
  my next goals, as soon as this patch is commit.

I believe, adding generic way to options extension is better way than
targeting specific options. Don't you?

I believe Nikolay's patch needs review and support. As you're interesting
to the problem, may you at least look at his suggestion and analyze it from
the point of view of your task?

-------
regards
Yura Sokolov aka funny-falcon

  6. Re: Allow table AMs to define their own reloptions

    Julien Tachoires <julien@tachoires.me> — 2025-03-29T07:46:01Z

    On Sun, Mar 02, 2025 at 02:23:54PM +0100, Julien Tachoires wrote:
> On Sun, Mar 02, 2025 at 09:56:41AM +0100, Julien Tachoires wrote:
> > With the help of the new TAM routine 'relation_options', table access 
> > methods can with this patch define their own reloptions 
> > parser/validator.
> > 
> > These reloptions can be set via the following commands:
> > 1. CREATE TABLE ... USING table_am
> >        WITH (option1='value1', option2='value2');
> > 2. ALTER TABLE ...
> >        SET (option1 'value1', option2 'value2');
> > 3. ALTER TABLE ... SET ACCESS METHOD table_am
> >        OPTIONS (option1 'value1', option2 'value2');
> > 
> > When changing table's access method, the settings inherited from the 
> > former TAM can be dropped (if not supported by the new TAM) via: DROP 
> > option, or, updated via: SET option 'value'.
> > 
> > Currently, tables using different TAMs than heap are able to use heap's 
> > reloptions (fillfactor, toast_tuple_target, etc...). With this patch 
> > applied, this is not the case anymore: if the TAM needs to have access 
> > to similar settings to heap ones, they have to explicitly define them.
> > 
> > The 2nd patch file includes a new test module 'dummy_table_am' which 
> > implements a dummy table access method utilized to exercise TAM 
> > reloptions. This test module is strongly based on what we already have 
> > in 'dummy_index_am'. 'dummy_table_am' provides a complete example of TAM 
> > reloptions definition.
> > 
> > This work is directly derived from SadhuPrasad's patch here [2]. Others 
> > attempts were posted here [1] and here [3].
> > 
> > [1] https://www.postgresql.org/message-id/flat/429fb58fa3218221bb17c7bf9e70e1aa6cfc6b5d.camel%40j-davis.com
> > [2] https://www.postgresql.org/message-id/flat/CAFF0-CG4KZHdtYHMsonWiXNzj16gWZpduXAn8yF7pDDub+GQMg@mail.gmail.com
> > [3] https://www.postgresql.org/message-id/flat/AMUA1wBBBxfc3tKRLLdU64rb.1.1683276279979.Hmail.wuhao%40hashdata.cn
> 
> Please find a new version including minor fixes: 'TAM' terms are
> replaced by 'table AM'

Please find a new rebased version. 

-- 
Julien Tachoires

  7. Re: Allow table AMs to define their own reloptions

    Julien Tachoires <julien@tachoires.me> — 2025-05-26T11:06:19Z

    On Sat, Mar 29, 2025 at 08:46:01AM +0100, Julien Tachoires wrote:
> On Sun, Mar 02, 2025 at 02:23:54PM +0100, Julien Tachoires wrote:
> > On Sun, Mar 02, 2025 at 09:56:41AM +0100, Julien Tachoires wrote:
> > > With the help of the new TAM routine 'relation_options', table access 
> > > methods can with this patch define their own reloptions 
> > > parser/validator.
> > > 
> > > These reloptions can be set via the following commands:
> > > 1. CREATE TABLE ... USING table_am
> > >        WITH (option1='value1', option2='value2');
> > > 2. ALTER TABLE ...
> > >        SET (option1 'value1', option2 'value2');
> > > 3. ALTER TABLE ... SET ACCESS METHOD table_am
> > >        OPTIONS (option1 'value1', option2 'value2');
> > > 
> > > When changing table's access method, the settings inherited from the 
> > > former TAM can be dropped (if not supported by the new TAM) via: DROP 
> > > option, or, updated via: SET option 'value'.
> > > 
> > > Currently, tables using different TAMs than heap are able to use heap's 
> > > reloptions (fillfactor, toast_tuple_target, etc...). With this patch 
> > > applied, this is not the case anymore: if the TAM needs to have access 
> > > to similar settings to heap ones, they have to explicitly define them.
> > > 
> > > The 2nd patch file includes a new test module 'dummy_table_am' which 
> > > implements a dummy table access method utilized to exercise TAM 
> > > reloptions. This test module is strongly based on what we already have 
> > > in 'dummy_index_am'. 'dummy_table_am' provides a complete example of TAM 
> > > reloptions definition.
> > > 
> > > This work is directly derived from SadhuPrasad's patch here [2]. Others 
> > > attempts were posted here [1] and here [3].
> > > 
> > > [1] https://www.postgresql.org/message-id/flat/429fb58fa3218221bb17c7bf9e70e1aa6cfc6b5d.camel%40j-davis.com
> > > [2] https://www.postgresql.org/message-id/flat/CAFF0-CG4KZHdtYHMsonWiXNzj16gWZpduXAn8yF7pDDub+GQMg@mail.gmail.com
> > > [3] https://www.postgresql.org/message-id/flat/AMUA1wBBBxfc3tKRLLdU64rb.1.1683276279979.Hmail.wuhao%40hashdata.cn
> > 
> > Please find a new version including minor fixes: 'TAM' terms are
> > replaced by 'table AM'
> 
> Please find a new rebased version. 

New rebased version.

-- 
Julien Tachoires