Re: Slowness of extended protocol
От | Robert Haas |
---|---|
Тема | Re: Slowness of extended protocol |
Дата | |
Msg-id | CA+TgmoYrnf+M+BWbLqWiyX9s5Knddk7xL_t7cXXpuGm8trvLqA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Slowness of extended protocol (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Wed, Aug 10, 2016 at 11:50 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> Sure, but I don't want the application to have to know about that, and >> I don't really think the driver should need to know about that either. >> Your point, as I understand it, is that sufficiently good query >> caching in the driver can ameliorate the problem, and I agree with >> that. > > I don't, actually. If a particular application has a query mix that gets > a good win from caching query plans, it should already be using prepared > statements. The fact that that's not a particularly popular thing to do > isn't simply because people are lazy, it's because they've found out that > it isn't worth the trouble for them. Putting query caching logic into > drivers isn't going to improve performance for such cases, and it could > very possibly make things worse. The driver is the place with the > absolute least leverage for implementing caching; it has no visibility > into either the application or the server. I didn't mean to imply, in any way, that it is an ideal solution - just that people use it successfully. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: