Re: [v9.5] Custom Plan API

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: [v9.5] Custom Plan API
Дата
Msg-id CA+U5nMJrJ7MWtXZv-PaaeZS+QbEkO_5qSek_FMhQY_3VQ3TUTg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [v9.5] Custom Plan API  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: [v9.5] Custom Plan API
Список pgsql-hackers
On 7 May 2014 17:43, Stephen Frost <sfrost@snowman.net> wrote:
> * Simon Riggs (simon@2ndQuadrant.com) wrote:
>> IMHO we would not want to add indexes to every column, on every table,
>> nor would we wish to use lookaside for all tables. It is a good thing
>> to be able to add optimizations for individual tables. GPUs are not
>> good for everything; it is good to be able to leverage their
>> strengths, yet avoid their weaknesses.
>
> It's the optimizer's job to figure out which path to pick though, based
> on which will have the lowest cost.

Of course. I'm not suggesting otherwise.

>> If do you want that, you can write an Event Trigger that automatically
>> adds a lookaside for any table.
>
> This sounds terribly ugly and like we're pushing optimization decisions
> on to the user instead of just figuring out what the best answer is.

I'm proposing that we use a declarative approach, just like we do when
we say CREATE INDEX.

The idea is that we only consider a lookaside when a lookaside has
been declared. Same as when we add an index, the optimizer considers
whether to use that index. What we don't want to happen is that the
optimizer considers a GIN plan, even when a GIN index is not
available.

I'll explain it more at the developer meeting. It probably sounds a
bit weird at first.

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



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: PGDLLEXPORTing all GUCs?
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers