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
