Re: [v9.5] Custom Plan API

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: [v9.5] Custom Plan API
Дата
Msg-id CA+U5nMK3LskgwvJHbLTe+GpGOtq97bYTJMTJC2v8872Ofotygg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [v9.5] Custom Plan API  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
On 8 May 2014 20:10, Stephen Frost <sfrost@snowman.net> wrote:

>> * A USERSET mechanism to allow users to turn it off for testing or
>> otherwise, at user, database level
>
> If we re-implement our existing components through this ("eat our own
> dogfood" as it were), I'm not sure that we'd be able to have a way to
> turn it on/off..  I realize we wouldn't have to, but then it seems like
> we'd have two very different code paths and likely a different level of
> support / capability afforded to "external" storage systems and then I
> wonder if we're not back to just FDWs again..

We have SET enable_hashjoin = on | off

I would like a way to do the equivalent of SET enable_mycustomjoin =
off so that when it starts behaving weirdly in production, I can turn
it off so we can prove that is not the casue, or keep it turned off if
its a problem. I don't want to have to call a hook and let the hook
decide whether it can be turned off or not.

Postgres should be in control of the plugin, not give control to the
plugin every time and hope it gives us control back.

(I'm trying to take the "FDW isn't the right way" line of thinking to
its logical conclusions, so we can decide).

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Sending out a request for more buildfarm animals?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [v9.5] Custom Plan API