Martijn van Oosterhout wrote:
>>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.

ok. Good point.

>>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.

Of course I didn't mean only the parse was to be saved. The planning
goes there too.

Thanks for the explanation.

> Have a nice day,

The same!

Marcus

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings