On 7 May 2014 02:05, Kouhei Kaigai <kai...@ak.jp.nec.com> wrote: > (1) DDL support and system catalog > > Simon suggested that DDL command should be supported to track custom- > plan providers being installed, and to avoid nonsense hook calls > if it is an obvious case that custom-plan provider can help. It also > makes sense to give a chance to load extensions once installed. > (In the previous design, I assumed modules are loaded by LOAD command > or *_preload_libraries parameters).
I've tried hard to bend my mind to this and its beginning to sink in. We've already got pg_am for indexes, and soon to have pg_seqam for sequences. It would seem normal and natural to have * pg_joinam catalog table for "join methods" with a join method API Which would include some way of defining which operators/datatypes we consider this for, so if PostGIS people come up with some fancy GIS join thing, we don't invoke it every time even when its inapplicable. I would prefer it if PostgreSQL also had some way to control when the joinam was called, possibly with some kind of table_size_threshold on the AM tuple, which could be set to >=0 to control when this was even considered. * pg_scanam catalog table for "scan methods" with a scan method API Again, a list of operators that can be used with it, like indexes and operator classes By analogy to existing mechanisms, we would want * A USERSET mechanism to allow users to turn it off for testing or otherwise, at user, database level We would also want * A startup call that allows us to confirm it is available and working correctly, possibly with some self-test for hardware, performance confirmation/derivation of planning parameters * Some kind of trace mode that would allow people to confirm the outcome of calls * Some interface to the stats system so we could track the frequency of usage of each join/scan type. This would be done within Postgres, tracking the calls by name, rather than trusting the plugin to do it for us > I tried to implement the following syntax: > > CREATE CUSTOM PLAN <name> FOR (scan|join|any) HANDLER <func_name>; Not sure if we need that yet -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
