Re: Cached/global query plans, autopreparation

2018-03-02 21:51 GMT+01:00 Tom Lane : > Andres Freund writes: > > On 2018-03-02 15:29:09 -0500, Bruce Momjian wrote: > >> While I have heard people complain about how other databases cache > >> prepare plans, I have heard few complaints about the Postgres

Re: Cached/global query plans, autopreparation

Andres Freund writes: > On 2018-03-02 15:29:09 -0500, Bruce Momjian wrote: >> While I have heard people complain about how other databases cache >> prepare plans, I have heard few complaints about the Postgres approach, >> and I haven't even heard of people asking to control

Re: Cached/global query plans, autopreparation

On 2018-03-02 15:29:09 -0500, Bruce Momjian wrote: > Postgres uses a conservative method for reusing plans with previous > constants, as described in the PREPARE manual page: > > https://www.postgresql.org/docs/10/static/sql-prepare.html > Prepared statements can use generic plans

Re: Cached/global query plans, autopreparation

On Thu, Feb 15, 2018 at 03:00:17PM +0100, Shay Rojansky wrote: > Just wanted to say that I've seen more than 10% improvement in some real-world > application when preparation was done properly. Also, I'm assuming that > implementing this wouldn't involve "rewriting substantial part of Postgres >

Re: Cached/global query plans, autopreparation

On Thu, Feb 15, 2018 at 8:00 AM, Shay Rojansky wrote: > I am an author of one of the proposal (autoprepare which is in commit fest >> now), but I think that sooner or later Postgres has to come to solution >> with shared DB caches/prepared plans. >> Please correct me if I am

Re: Cached/global query plans, autopreparation

> > I am an author of one of the proposal (autoprepare which is in commit fest > now), but I think that sooner or later Postgres has to come to solution > with shared DB caches/prepared plans. > Please correct me if I am wrong, but it seems to me that most of all other > top DBMSes having

Re: Cached/global query plans, autopreparation

> > > 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

Re: Cached/global query plans, autopreparation

On 13.02.2018 20:13, Shay Rojansky wrote: Hi all, Was wondering if anyone has a reaction to my email below about statement preparation, was it too long? :) (and sorry for top-posting) On Tue, Feb 6, 2018 at 9:27 PM, Shay Rojansky > wrote: Hi

Re: Cached/global query plans, autopreparation

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 he...@visionlink.org Site |

Re: Cached/global query plans, autopreparation

Andres Freund 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

Re: Cached/global query plans, autopreparation

​Coming from a PHP application I have several of the same concerns and wishes​. Given that php can not share any (resources) between requests it would be impossible to accomplish what you have in .NET. We still prepare statements though for use in result sets and other loops (ORM driven). I'm

Re: Cached/global query plans, autopreparation

Hi all, Was wondering if anyone has a reaction to my email below about statement preparation, was it too long? :) (and sorry for top-posting) On Tue, Feb 6, 2018 at 9:27 PM, Shay Rojansky wrote: > Hi all. > > Various versions of having PostgreSQL caching and/or autopreparing >

Cached/global query plans, autopreparation

Hi all. Various versions of having PostgreSQL caching and/or autopreparing statement plans have been discussed ( https://www.postgresql.org/message-id/op.t9ggb3wacigqcu%40apollo13.peufeu.com , https://www.postgresql.org/message-id/8e76d8fc-8b8c-14bd-d4d1-e9cf193a74f5%40postgrespro.ru), without