From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
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 03:12:14 |
Message-ID: | 23362.1097118734@sss.pgh.pa.us |
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.
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 | Alan Stange | 2004-10-07 03:14:20 | Re: Excessive context switching on SMP Xeons |
Previous Message | Neil Conway | 2004-10-07 01:29:07 | Re: The never ending quest for clarity on shared_buffers |