Thread: Allow table AMs to define their own reloptions
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
Attachment
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
Attachment
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
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
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