Re: Cached/global query plans, autopreparation

Поиск
Список
Период
Сортировка
От henry@visionlink.org
Тема Re: Cached/global query plans, autopreparation
Дата
Msg-id CACOdEDh955G0JtoGRCVQbEXjyZ6oa9BNzarRSTOezAFvsEA__Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Cached/global query plans, autopreparation  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Any idea on how feasible it would be as an extention or is the work too central to abstract that way?

Chet Henry
Senior Software Developer - Dev Ops Liaison
VisionLink, Inc.
3101 Iris Ave, Ste 240
Boulder, CO 80301
 henry@visionlink.org

      
Site | Blog | Join Our Team | Try a Demo
Twitter   Pinterest   Facebook   LinkedIn   YouTube

On Wed, Feb 14, 2018 at 2:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Andres Freund <andres@anarazel.de> writes:
> On 2018-02-13 09:13:09 -0800, Shay Rojansky wrote:
>> Was wondering if anyone has a reaction to my email below about statement
>> preparation, was it too long? :)

> Well, the issue is that implementing this is a major piece of work. This
> post doesn't offer either resources nor a simpler way to do so. There's
> no huge debate about the benefit of having a global plan cache, so I'm
> not that surprised there's not a huge debate about a post arguing that
> we should have one.

Actually, I'm pretty darn skeptical about the value of such a cache for
most use-cases.  But as long as it can be turned off and doesn't leave
residual overhead nor massive added code cruft, I won't stand in the way
of someone else investing their time in it.

In any case, as you say, it's moot until somebody steps up to do it.

                        regards, tom lane


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

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: reorganizing partitioning code
Следующее
От: Amit Langote
Дата:
Сообщение: Re: [HACKERS] path toward faster partition pruning