Re: Caching of Queries
От | Tatsuo Ishii |
---|---|
Тема | Re: Caching of Queries |
Дата | |
Msg-id | 20041007.161842.77062117.t-ishii@sra.co.jp обсуждение исходный текст |
Ответ на | Re: Caching of Queries (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Caching of Queries
|
Список | pgsql-performance |
> Tatsuo Ishii <t-ishii@sra.co.jp> writes: > > First, it's not a particular problem with pgpool. As far as I know any > > connection pool solution has exactly the same problem. Second, it's > > easy to fix if PostgreSQL provides a functionarity such as:"drop all > > temporary tables if any". > > I don't like that definition exactly --- it would mean that every time > we add more backend-local state, we expect client drivers to know to > issue the right incantation to reset that kind of state. > > I'm thinking we need to invent a command like "RESET CONNECTION" that > resets GUC variables, drops temp tables, forgets active NOTIFYs, and > generally does whatever else needs to be done to make the session state > appear virgin. When we add more such state, we can fix it inside the > backend without bothering clients. Great. It's much better than I propose. > I now realize that our "RESET ALL" command for GUC variables was not > fully thought out. We could possibly redefine it as doing the above, > but that might break some applications ... > > regards, tom lane >
В списке pgsql-performance по дате отправления: