Merlin Moncure writes:
> On Wed, Oct 13, 2010 at 10:14 AM, Tom Lane wrote:
>> It's possible that at some point we'll try to introduce plan caching
>> for non-inlined SQL functions.
> hm, I think the search_path/function plan issue would have to be dealt
> with before doing this --
Yeah, perhaps
On Wed, Oct 13, 2010 at 10:14 AM, Tom Lane wrote:
> It's possible that at some point we'll try to introduce plan caching
> for non-inlined SQL functions.
hm, I think the search_path/function plan issue would have to be dealt
with before doing this -- a while back IIRC you suggested function
plans
Wow. Thanks so much to all of you for the thoughtful and helpful
responses!
Reuven
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
"Reuven M. Lerner" writes:
> All of the database-related logic for this application is in server-side
> functions, written in PL/PgSQL. That is, the application never issues a
> SELECT or INSERT; rather, it invokes a function with parameters, and the
> function handles the query. It's not unusu
On Wed, Oct 13, 2010 at 3:30 AM, Reuven M. Lerner wrote:
> Hi, everyone. I'm working with a client to try to optimize their use of
> PostgreSQL. They're running 8.3 on a Windows platform, packaged as part
> of a physical product that is delivered to customers.
>
> We're planning to upgrade to 9.
On 13/10/2010 3:30 PM, Reuven M. Lerner wrote:
My question is whether this is somehow to be expected. Under what
conditions will SQL functions be slower than PL/PgSQL functions?
The main cases I can think of:
- Where the SQL function is inlined (PL/PgSQL functions can't be
inlined, some SQL
Hi, everyone. I'm working with a client to try to optimize their use of
PostgreSQL. They're running 8.3 on a Windows platform, packaged as part
of a physical product that is delivered to customers.
We're planning to upgrade to 9.0 at some point in the coming months, but
this question is relevant
