On Wed, Dec 29, 2021 at 10:38 PM Sadhuprasad Patro <b.sadhu@gmail.com> wrote:
Hi,
Currently all the storage options for a table are very much specific to the heap but a different AM might need some user defined AM specific parameters to help tune the AM. So here is a patch which provides an AM level routine so that instead of getting parameters validated using “heap_reloptions” it will call the registered AM routine.
This is a good idea. +1.
e.g: -- create a new access method and table using this access method CREATE ACCESS METHOD myam TYPE TABLE HANDLER <new_tableam_handler>;
CREATE TABLE mytest (a int) USING myam ;
--a new parameter is to set storage parameter for only myam as below ALTER TABLE mytest(squargle_size = '100MB');
I syntax here is, ALTER TABLE <table_name> SET ( attribute_option = value );
The user-defined parameters will have meaning only for the "myam", otherwise error will be thrown. Our relcache already allows the AM-specific cache to be stored for each relation.
Open Question: When a user changes AM, then what should be the behavior for not supported storage options? Should we drop the options and go with only system storage options? Or throw an error, in which case the user has to clean the added parameters.
I think throwing an error makes more sense, so that the user can clean that.