Re: bind variables, soft vs hard parse - Mailing list pgsql-hackers

From Marcus Engene
Subject Re: bind variables, soft vs hard parse
Date
Msg-id 437AF999.70601@engene.se
Whole thread Raw
In response to Re: bind variables, soft vs hard parse  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: bind variables, soft vs hard parse  ("Jim C. Nasby" <jnasby@pervasive.com>)
List 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


pgsql-hackers by date:

Previous
From: Marcus Engene
Date:
Subject: Re: bind variables, soft vs hard parse
Next
From: Michael Glaesemann
Date:
Subject: Re: Long-time 7.4 contrib failure Mac OS X 10.3.8