Re: [HACKERS] Dynamically adding index types (was GIT indexes)
On Wed, 2007-09-19 at 10:37 -0400, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: We're able to dynamically add AMs in the way you suggest, but there is no way to alter the RMgrTable to either add a new RM or re-assign one of the unused RMs. Hmmm... 1. Remove the Const in front of RmgrTable in rmgr.c. That would allow re-assignment of the two existing unused RMs. Useless, as there's no way for an add-on AM to cause the value to be changed before recovery begins. OK, sounds like the only way is to have a dedicated plug-in. if (resource_manager_hook) set RmgrTable in plugin else normal static definition (but no longer Const) ...or variations of the above depending upon whether we want to allow redefining existing Rmgrs - not something I personally want. Plus something to say xlog record found for unknown Rmgr. Plus changes to all places that refer to RM_MAX_ID and replace with a global value of RmgrTableEntries. We can then get rid of the two reserved Rmgr values... Will that do it? -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Dynamically adding index types (was GIT indexes)
On Tue, 2007-08-07 at 17:03 -0400, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: How hard will it be to add the infrastructure to allow new index types to be added to the server dynamically? INSERT INTO pg_am VALUES (...); I don't really think we need more than that, at least not till non-core index AMs are a whole lot thicker on the ground than they are today. We're able to dynamically add AMs in the way you suggest, but there is no way to alter the RMgrTable to either add a new RM or re-assign one of the unused RMs. So we can add a new AM, but it can't write WAL in a different way to existing RMs. We could either: 1. Remove the Const in front of RmgrTable in rmgr.c. That would allow re-assignment of the two existing unused RMs. 2. Create a new catalog table pg_rm and some brief machinery to populate the RmgrTable from pg_rm. That would allow dynamically adding RMs. Seems like we could do (1) for 8.3 easily enough. Thoughts, please? -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Dynamically adding index types (was GIT indexes)
Simon Riggs [EMAIL PROTECTED] writes: We're able to dynamically add AMs in the way you suggest, but there is no way to alter the RMgrTable to either add a new RM or re-assign one of the unused RMs. Hmmm... 1. Remove the Const in front of RmgrTable in rmgr.c. That would allow re-assignment of the two existing unused RMs. Useless, as there's no way for an add-on AM to cause the value to be changed before recovery begins. 2. Create a new catalog table pg_rm and some brief machinery to populate the RmgrTable from pg_rm. That would allow dynamically adding RMs. Also useless --- what if pg_rm is damaged or missing? Even if it's there, how would recovery be able to tell which rows are valid? We certainly don't want it trying to do pg_clog probes. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
