Interesting. It's quite a hairy plan even though all the branches are
cut off by conditions ("never executed") so the query yields 0 rows.
0.018 is not a bad timing for that.
However, if you run this query with different parameters, the result
could be quite sad.
There are some deeply neste
Hi,
Le 16 juil. 09 à 11:52, Andres Freund a écrit :
If I interpret those findings correcty the execution is approx. as
fast as DB2,
only DB2 is doing automated plan caching while pg is not.
If it _really_ is necessary that this is that fast, you can prepare
the query
like I showed.
A for
On Thursday 16 July 2009 11:46:18 ning wrote:
> I'm sorry, they are in milliseconds, not seconds.
> The time used is quite same to the result of "explain analyze select
> " I pasted above,
> which was " Total runtime: 0.479 ms".
Yea. Unfortunately that time does not including planning time. If
I'm sorry, they are in milliseconds, not seconds.
The time used is quite same to the result of "explain analyze select
" I pasted above,
which was " Total runtime: 0.479 ms".
Greetings,
Ning
On Thu, Jul 16, 2009 at 6:33 PM, Andres Freund wrote:
> On Thursday 16 July 2009 11:30:00 ning wrote:
Hi Andres,
By executing
#explain analyze execute test_query;
the first execution cost 0.389 seconds
the second cost 0.285 seconds
Greetings,
Ning
On Thu, Jul 16, 2009 at 4:45 PM, Andres Freund wrote:
> On Thursday 16 July 2009 03:11:29 ning wrote:
>> Hi Andres,
>>
>> The log for the test you s
On Thursday 16 July 2009 11:30:00 ning wrote:
> Hi Andres,
>
> By executing
> #explain analyze execute test_query;
>
> the first execution cost 0.389 seconds
> the second cost 0.285 seconds
Seconds or milliseconds?
If seconds that would be by far slower than the plain SELECT, right?
Andres
--
S
On Thursday 16 July 2009 03:11:29 ning wrote:
> Hi Andres,
>
> The log for the test you suggested is as follows in PostgreSQL8.2.4,
> but I cannot find a clue to prove or prove not PostgreSQL is doing
> plan caching.
Well. How long is the PREPARE and the EXECUTEs taking?
Andres
--
Sent via pgsq
Hi Andres,
The log for the test you suggested is as follows in PostgreSQL8.2.4,
but I cannot find a clue to prove or prove not PostgreSQL is doing
plan caching.
Best regards,
Ning
-
job=# prepare test_query as SELECT
oid_,void,nameId,tag,intval,lowerbound,upperbound,crossfeeddir,feeddir,unit
Hi Mike,
Thank you for your explanation.
The "explain analyze" command used is as follows, several integers are
bound to '?'.
-
SELECT
oid_,void,nameId,tag,intval,lowerbound,upperbound,crossfeeddir,feeddir,units,opqval,bigval,strval
FROM (SELECT
attributeOf,void,nameId,tag,intval,lowerbound,
On Wednesday 15 July 2009 10:27:50 Craig Ringer wrote:
> On Wed, 2009-07-15 at 12:10 +0900, ning wrote:
> > First execution: PostgreSQL 0.006277 seconds / DB2 0.009028 seconds
> > Second execution: PostgreSQL 0.005932 seconds / DB2 0.000332 seconds
>
> Actually, on second thoughts that looks a lot
ning wrote:
The log is really long,
Which usually signals a problem with the query.
but I compared the result of "explain analyze"
for first and later executions, except for 3 "time=XXX" numbers, they
are identical.
They are supposed to be identical unless something is really badly broke
Hi Greg,
I am doing performance test by running unit test program to compare
time used on PostgreSQL and DB2. As you pointed out, there are cases
that PostgreSQL is faster. Actually in real world for my application,
repeatedly executing same query statement will hardly happen. I am
investigating t
Hi Craig,
The log is really long, but I compared the result of "explain analyze"
for first and later executions, except for 3 "time=XXX" numbers, they
are identical.
I agree with you that PostgreSQL is doing different level of caching,
I just wonder if there is any way to speed up PostgreSQL in th
On Wed, Jul 15, 2009 at 9:27 AM, Craig
Ringer wrote:
> On Wed, 2009-07-15 at 12:10 +0900, ning wrote:
>
>> First execution: PostgreSQL 0.006277 seconds / DB2 0.009028 seconds
>> Second execution: PostgreSQL 0.005932 seconds / DB2 0.000332 seconds
>
> Actually, on second thoughts that looks a lot li
On Wed, 2009-07-15 at 12:10 +0900, ning wrote:
> First execution: PostgreSQL 0.006277 seconds / DB2 0.009028 seconds
> Second execution: PostgreSQL 0.005932 seconds / DB2 0.000332 seconds
Actually, on second thoughts that looks a lot like DB2 is caching the
query results and is just returning the
On Wed, 2009-07-15 at 12:10 +0900, ning wrote:
> Hi,
>
> I am transplanting an application to use PostgreSQL8.2.4 instead of DB2 9.1.
> CLI was used to connect to DB2, and ODBC is used to connect to PostgreSQL.
> The query statement is as follows:
> PostgreSQL cost nearly the same time but DB2 ra
16 matches
Mail list logo
