Re: [v9.5] Custom Plan API
От | Simon Riggs |
---|---|
Тема | Re: [v9.5] Custom Plan API |
Дата | |
Msg-id | CA+U5nMJKgMjYCVmnSriRrYzPE9xgP4NhL6qTwLq=9fGPhh3efQ@mail.gmail.com обсуждение исходный текст |
Ответ на | [v9.5] Custom Plan API (Kouhei Kaigai <kaigai@ak.jp.nec.com>) |
Ответы |
Re: [v9.5] Custom Plan API
|
Список | pgsql-hackers |
On 7 May 2014 02:05, Kouhei Kaigai <kaigai@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
В списке pgsql-hackers по дате отправления: