From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | matt(at)ymogen(dot)net, pg(at)rbt(dot)ca, awerman2(at)hotmail(dot)com, scottakirkwood(at)gmail(dot)com, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Caching of Queries |
Date: | 2004-10-07 07:18:42 |
Message-ID: | 20041007.161842.77062117.t-ishii@sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Aaron Werman | 2004-10-07 11:30:07 | Re: Data warehousing requirements |
Previous Message | Alan Stange | 2004-10-07 03:14:20 | Re: Excessive context switching on SMP Xeons |