>>> 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
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
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
> w
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
usi
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
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
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), smal
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,
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
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
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, s
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 ex
Theo Kramer a écrit :
On Wed, 2007-10-10 at 17:00 +0200, Cédric Villemain wrote:
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' http://www.postgresql.org/doc
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 th
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 17:00 +0200, Cédric Villemain wrote:
>
> 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' http://www.postgresql.org/docs/8.2/interactiv
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
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 output as follows
rascal
18 matches
Mail list logo
