On Wed, Nov 16, 2005 at 09:56:44AM +0100, Marcus Engene wrote:
> Douglas McNaught wrote:
> >You can do this (or close to it) but you need to explicitly PREPARE
> >the query (or use the protocol-level prepare, which some client
> >libraries will do for you). See the SQL documentation for PREPARE.
>
> But this is of no use in a web-context. According to the docs, this
> prepare is per session.
Unless you use something like pgpool, in which case a single session
may include multiple requests.
> This sql cache I think is a really good thing. Is there a reason
> Postgres hasn't got it? Would it be very hard to implement? From
> a naive perspective; make a hashvalue from the sql-string to
> quickly find the cached one, a "last used"-list for keeping
> track of which to delete when cache full etc seems close to
> trivial. Does the architecture/internal flow make it hard
> actually reuse the query data structure?
It's hard to reuse the structure. Also, things like search_path mean
that the same query text can mean completely different things in
different backends. Most of the time it's planning that dominates, not
parsing so storing just the parser output seems somewhat useless.
Unless you've thought of a new way to do it.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.
