On Wed, 2003-10-01 at 20:25, Jingren Zhou wrote:
From the document, it seems that PREPARE/EXECUTE works only in the same
session. I am wondering whether postgres can prepare a query (save the plan)
for difference backends.
The decision to store prepared statements per-backend, rather than in
On Wed, 1 Oct 2003, Jingren Zhou wrote:
Hi,
From the document, it seems that PREPARE/EXECUTE works only in the same
session. I am wondering whether postgres can prepare a query (save the plan)
for difference backends.
I am working on a project which requires executing psql -c 'query' in
Neil Conway [EMAIL PROTECTED] writes:
The decision to store prepared statements per-backend, rather than in
shared memory, was made deliberately. In fact, an early version of the
PREPARE/EXECUTE patch (written by Karel Zak) stored prepared statements
in shared memory. But I decided to remove
On Wed, 2003-10-01 at 22:43, Tom Lane wrote:
Another issue is that we currently don't have a mechanism for flushing
query plans when they become obsolete (eg, an index is added or
removed). Locally-cached plans are relatively easy to refresh: just
start a fresh session. A shared plan cache
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
On Wed, 2002-10-23 at 10:39, Greg Copeland wrote:
If you were using them that frequently, couldn't you just keep a
persistent connection? If it's not used that often, wouldn't the
overhead of preparing the query following a new connection become noise?
Especially by the time you add in the
On Wed, Oct 23, 2002 at 11:02:14AM -0400, Tom Lane wrote:
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= [EMAIL PROTECTED] writes:
I wonder if there is a way to store a parsed/rewritten/planned query in
a table so that it can be loaded again.
The original version of the PREPARE patch used a
If you were using them that frequently, couldn't you just keep a
persistent connection? If it's not used that often, wouldn't the
overhead of preparing the query following a new connection become noise?
Greg
On Wed, 2002-10-23 at 09:24, Hans-Jürgen Schönig wrote:
First of all PREPARE/EXECUTE
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= [EMAIL PROTECTED] writes:
I wonder if there is a way to store a parsed/rewritten/planned query in
a table so that it can be loaded again.
The original version of the PREPARE patch used a shared-across-backends
cache for PREPAREd statements. We rejected
On Wed, Oct 23, 2002 at 18:04:01 +0200,
Hans-Jürgen Schönig [EMAIL PROTECTED] wrote:
An example:
I have a join across 10 tables + 2 subselects across 4 tables
on the machine I use for testing:
planner: 12 seconds
executor: 1 second
The application will stay the same forever.
I
Bruno Wolff III [EMAIL PROTECTED] writes:
Hans-Jürgen Schönig [EMAIL PROTECTED] wrote:
I have a join across 10 tables + 2 subselects across 4 tables
on the machine I use for testing:
planner: 12 seconds
executor: 1 second
One option you have is to explicitly give the join order.
Yes,
This is exactly what we do in case of complex stuff. I know that it can
help to reduce the problem for the planner.
However: If you have explicit joins across 10 tables the SQL statement
is not that readable any more and it is still slower than a prepared
execution plan.
I guess it is worth
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
Could you use some form of connection proxy where the proxy is actually
keeping persistent connections but your application is making transient
connections to the proxy? I believe this would result in the desired
performance boost and behavior.
Now, the next obvious question...anyone know of any
Greg Copeland wrote:
Could you use some form of connection proxy where the proxy is actually
keeping persistent connections but your application is making transient
connections to the proxy? I believe this would result in the desired
performance boost and behavior.
Now, the next obvious
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
Zeugswetter Andreas SB SD [EMAIL PROTECTED] 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
17 matches
Mail list logo
