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 | ||||||
| |||||||
Site | Blog | Join Our Team | Try a Demo | |||||||
![]() ![]() ![]() ![]() ![]() |
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 по дате отправления: