Re: Caching of Queries - Mailing list pgsql-performance

From Tatsuo Ishii
Subject Re: Caching of Queries
Date
Msg-id 20041007.161842.77062117.t-ishii@sra.co.jp
Whole thread Raw
In response to Re: Caching of Queries  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Caching of Queries  (Bruce Momjian <pgman@candle.pha.pa.us>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Caching of Queries
Next
From: "Aaron Werman"
Date:
Subject: Re: Data warehousing requirements