On Thu, 2007-10-11 at 16:04 -0400, Merlin Moncure wrote:
On 10/11/07, Andrew - Supernews [EMAIL PROTECTED] wrote:
On 2007-10-10, Theo Kramer [EMAIL PROTECTED] wrote:
When doing a 'manual' prepare and explain analyze I get the following
rascal=# prepare cq (char(12), smallint, integer)
On Thu, 2007-10-11 at 13:28 -0400, Merlin Moncure wrote:
On 10/11/07, Theo Kramer [EMAIL PROTECTED] wrote:
On Thu, 2007-10-11 at 10:12 +0100, Richard Huxton wrote:
Theo Kramer wrote:
So I suspect that there is something more fundamental here...
OK, so there must be something
On Thu, 2007-10-11 at 18:28 +, Andrew - Supernews wrote:
On 2007-10-10, Theo Kramer [EMAIL PROTECTED] wrote:
When doing a 'manual' prepare and explain analyze I get the following
rascal=# prepare cq (char(12), smallint, integer) as SELECT oid,
calllog_mainteng, calllog_phase,
Theo Kramer wrote:
On Thu, 2007-10-11 at 18:28 +, Andrew - Supernews wrote:
When you do this from the application, are you passing it 3 parameters,
or 5? The plan is clearly taking advantage of the fact that the two
occurrences of $1 and $2 are known to be the same value; if your app is
On 10/12/07, Theo Kramer [EMAIL PROTECTED] wrote:
On Thu, 2007-10-11 at 16:04 -0400, Merlin Moncure wrote:
is this a converted cobol app?
:) - on the right track - it is a conversion from an isam based package
where I have changed the backed to PostgreSQL. Unfortunately there is
way too
On Fri, Oct 12, 2007 at 9:57 AM, in message
[EMAIL PROTECTED], Theo Kramer
[EMAIL PROTECTED] wrote:
select * from foo where
(a = a1 and b = b1 and c = c1) or
(a = a1 and b b1) or
(a a1)
order by a, b desc, c;
I have, however, found that transforming the above into a union
On Fri, 2007-10-12 at 09:02 -0400, Merlin Moncure wrote:
fwiw, I converted a pretty large cobol app (acucobol) to postgresql
backend translating queries on the fly. if this is a fresh effort,
you definately want to use the row-wise comparison feature of 8.2.
not only is it much simpler, it's
Theo Kramer a écrit :
On Wed, 2007-10-10 at 17:00 +0200, Cédric Villemain wrote:
snip
Reading the manual, you can learn that prepared statement can (not)
follow the same plan as direct query:
the plan is make before pg know the value of the variable.
See 'Notes'
Theo Kramer wrote:
Thanks, had missed that, however, I am afraid that I fail to see how
preparing a query using PQprepare() and then executing it using
PQexecPrepared(), is 8 thousand times slower than directly executing
it.,, ( 403386.583ms/50.0ms = 8067 ).
When doing a 'manual' prepare and
On Thu, 2007-10-11 at 10:12 +0100, Richard Huxton wrote:
Theo Kramer wrote:
So I suspect that there is something more fundamental here...
OK, so there must be something different between the two scenarios. It
can only be one of:
1. Query
2. DB Environment (user, locale, settings)
On 10/11/07, Theo Kramer [EMAIL PROTECTED] wrote:
On Thu, 2007-10-11 at 10:12 +0100, Richard Huxton wrote:
Theo Kramer wrote:
So I suspect that there is something more fundamental here...
OK, so there must be something different between the two scenarios. It
can only be one of:
On 2007-10-10, Theo Kramer [EMAIL PROTECTED] wrote:
When doing a 'manual' prepare and explain analyze I get the following
rascal=# prepare cq (char(12), smallint, integer) as SELECT oid,
calllog_mainteng, calllog_phase, calllog_self FROM calllog
WHERE calllog_mainteng = $1
AND calllog_phase
On 10/11/07, Andrew - Supernews [EMAIL PROTECTED] wrote:
On 2007-10-10, Theo Kramer [EMAIL PROTECTED] wrote:
When doing a 'manual' prepare and explain analyze I get the following
rascal=# prepare cq (char(12), smallint, integer) as SELECT oid,
calllog_mainteng, calllog_phase, calllog_self
Theo Kramer a écrit :
Hi
I have been having some serious performance issues when using prepared
statements which I can not re-produce when using a direct statement. Let
me try to explain
The query does an order by in descending order on several columns for
which an index exists.
The explain
On 10/10/07, Theo Kramer [EMAIL PROTECTED] wrote:
When running the query directly from psql it returns the required rows
in less than 100 milli-seconds.
However, when using a prepared statement from my C application on the
above query and executing it the query duration is as follows
...
On Wed, 2007-10-10 at 15:55 -0400, Jonah H. Harris wrote:
On 10/10/07, Theo Kramer [EMAIL PROTECTED] wrote:
When running the query directly from psql it returns the required rows
in less than 100 milli-seconds.
However, when using a prepared statement from my C application on the
above
16 matches
Mail list logo
