Re: Caching of Queries

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

In response to

Responses

Browse pgsql-performance by date

  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