
> The idea is not to have it accross multiple backends and having it in 
> sync with the tables in the database. This is not the point.
> My problem is that I have seen many performance critical applications 
> sending just a few complex queries to the server. The problem is: If you 
> have many queries where the relation "time planner"/"time executor" is 
> very high (eg. complex joins with just one value as the result).

The standard approach to such a scenario would imho be to write stored procedures
for the complex queries (e.g. plpgsql) and use that from the client.
Maybe even eliminate a few ping pongs between client and server.

Andreas

Wed, 23 Oct 2002 20:58:13 +0200
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
Re: PREPARE / EXECUTE
>
>
>
>The standard approach to such a scenario would imho be to write stored procedures
>for the complex queries (e.g. plpgsql) and use that from the client.
>Maybe even eliminate a few ping pongs between client and server.
>
>Andreas
>  
>

Does it reduce the time taken by the planner?
Are server side SQL functions optimized at runtime or at "create 
function" time?

If the function is optimized at runtime it is not a gain.

    Hans


-- 
*Cybertec Geschwinde u Schoenig*
Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria
Tel: +43/1/913 68 09; +43/664/233 90 75
www.postgresql.at <http://www.postgresql.at>, cluster.postgresql.at 
<http://cluster.postgresql.at>, www.cybertec.at 
<http://www.cybertec.at>, kernel.cybertec.at <http://kernel.cybertec.at>



Wed, 23 Oct 2002 21:09:45 +0200
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <hs@cybertec.at>
Re: PREPARE / EXECUTE
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> The standard approach to such a scenario would imho be to write
> stored procedures for the complex queries (e.g. plpgsql) and use
> that from the client.  Maybe even eliminate a few ping pongs between
> client and server.

Since PL/PgSQL cached query plans are flushed when the backend exits,
how would this help?

Regarding the original suggestion of storing prepared plans on disk, I
agree with Tom -- it's basically the same idea as storing plans in
shared memory, which we previously considered (and Karel implemented),
but ultimately decided to remove. IMHO, the utility of this feature
doesn't justify the problems that would come with implementing it (see
the archives for the original implementation discussions).

Cheers,

Neil

-- 
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC


23 Oct 2002 17:35:49 -0400
Neil Conway <neilc@samurai.com>
Re: PREPARE / EXECUTE