Re: [PATCH] Finally split StdRdOptions into HeapOptions and ToastOptions - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: [PATCH] Finally split StdRdOptions into HeapOptions and ToastOptions
Date
Msg-id 122658ed0a021799e4aa4b2c8c48ee51211625b2.camel@j-davis.com
Whole thread Raw
In response to Re: [PATCH] Finally split StdRdOptions into HeapOptions and ToastOptions  (Nikolay Shaplov <dhyan@nataraj.su>)
Responses Re: [PATCH] Finally split StdRdOptions into HeapOptions and ToastOptions  (Nikolay Shaplov <dhyan@nataraj.su>)
List pgsql-hackers
On Sun, 2020-09-13 at 19:04 +0300, Nikolay Shaplov wrote:
> Moving reloptions to AM code is the goal I am slowly moving to. I've
> started 
> some time ago with big patch 
> https://commitfest.postgresql.org/14/992/ and 
> have been told to split it into smaller parts. So I did, and this
> patch is 
> last step that cleans options related things up, and then actual
> moving can be 
> done.

Thank you for working on this.

Can you outline the plan for moving these options to the table AM to
make sure this patch is a step in the right direction?

I was trying to work through this problem as well[1], and there are a
few complications.

* Which options apply to any relation (of any table AM), and which
apply to only heaps? As far as I can tell, the only one that seems
heap-specific is "fillfactor".

* Toast tables can be any AM, as well, so if we accept new reloptions
for a custom AM, we also need to accept options for toast tables of
that AM.

* Implementation-wise, the bytea representation of the options is not
very easy to extend. Should we have a new text field in the catalog to
hold the custom options?

Regards,
    Jeff Davis

[1] 
https://www.postgresql.org/message-id/43c6ec161f930e385dbc3169a065a917cfc60714.camel%40j-davis.com




pgsql-hackers by date:

Previous
From: Arne Roland
Date:
Subject: Re: PATCH: generate fractional cheapest paths in generate_orderedappend_path
Next
From: David Rowley
Date:
Subject: Re: A few source files have the wrong copyright year