From: | Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com> |
---|---|
To: | Sadhuprasad Patro <b(dot)sadhu(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Per-table storage parameters for TableAM/IndexAM extensions |
Date: | 2022-01-04 07:32:36 |
Message-ID: | CAGPqQf2qmgod2fyOt1rZh6n+YEP_uga9oa8T0x6p-oTJWc5S2Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Dec 29, 2021 at 10:38 PM Sadhuprasad Patro <b(dot)sadhu(at)gmail(dot)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.
Here are a few quick cosmetic review comments:
1)
> @@ -1372,7 +1373,8 @@ untransformRelOptions(Datum options)
> */
> bytea *
> extractRelOptions(HeapTuple tuple, TupleDesc tupdesc,
> - amoptions_function amoptions)
> + amoptions_function amoptions,
> + reloptions_function taboptions)
>
Indentation has been changed and needs to be fixed.
2)
case RELKIND_MATVIEW:
> options = table_reloptions(taboptions, classForm->relkind,
> datum, false);
> break;
>
Going beyond line limit.
3)
diff --git a/src/backend/access/heap/heapam_handler.c
> b/src/backend/access/heap/heapam_handler.c
> index 9befe01..6324d7e 100644
> --- a/src/backend/access/heap/heapam_handler.c
> +++ b/src/backend/access/heap/heapam_handler.c
> @@ -2581,6 +2581,7 @@ static const TableAmRoutine heapam_methods = {
> .index_build_range_scan = heapam_index_build_range_scan,
> .index_validate_scan = heapam_index_validate_scan,
>
> + .taboptions = heap_reloptions,
>
Instead of taboptions can name this as relation_options to be in sink with
other members.
4)
@@ -2427,7 +2428,7 @@ do_autovacuum(void)
> */
> MemoryContextSwitchTo(AutovacMemCxt);
> tab = table_recheck_autovac(relid, table_toast_map, pg_class_desc,
> - effective_multixact_freeze_max_age);
> + classRel->rd_tableam->taboptions, effective_multixact_freeze_max_age);
> if (tab == NULL)
>
Split the another added parameter to function in the next line.
5)
Overall patch has many indentation issues, I would suggest running the
pgindent to fix those.
Regards
Rushabh Lathia
www.EnterpriseDB.com
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2022-01-04 07:55:34 | Re: psql - add SHOW_ALL_RESULTS option |
Previous Message | Peter Smith | 2022-01-04 06:45:39 | Re: row filtering for logical replication |