| From: | Marcus Engene <mengpg(at)engene(dot)se> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: bind variables, soft vs hard parse |
| Date: | 2005-11-16 09:19:21 |
| Message-ID: | 437AF999.70601@engene.se |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Glaesemann | 2005-11-16 09:48:38 | Re: Long-time 7.4 contrib failure Mac OS X 10.3.8 |
| Previous Message | Marcus Engene | 2005-11-16 09:11:38 | Re: bind variables, soft vs hard parse |