PostgreSQL JDBC - 8.0.1 performance question.

Author

8.0.1 performance question.

alvin.yk@gmail.com

2005-04-04, 8:04 pm

Hi,

I have just upgraded our db from 7.4.2 to 8.0.1 and we are doing some
testing. For some reasons, we have discovered that our application
performs much slower on 8.0.1.

My initial reaction was to turn on log_min_duration_sta
tement to see
what's happening. However, log_min_duration_sta
tement does not work
for JDBC clients in 8.0.1.

As a result, I modified log_statement to all. Without my application
doing anything, I see statements below being executed non-stop. Who
is triggering these statemetns? Is this normal? What am I doing
wrong?

I am using Fedora Core 1 - Kernel: 2.4.22-1.2174.nptl

Please help. Thanks.

PS. I sent this email to the performance list and Tom asked me to
check with this list. Therefore, here I am.

2005-04-04 18:05:00 CST PARSELOG: statement: SELECT attnotnull FROM
pg_catalog.pg_attribute WHERE attrelid = $1 AND attnum = $2
2005-04-04 18:05:00 CST PARSELOG: statement: SELECT def.adsrc FROM
pg_catalog.pg_class c JOIN pg_catalog.pg_attribute a ON
(a.attrelid=c.oid
) LEFT JOIN pg_catalog.pg_attrdef def ON (a.attrelid=def.adrelid AND
a.attnum = def.adnum) WHERE c.oid = $1 and a.attnum = $2 AND def.adsrc
L
IKE '%nextval(%'
2005-04-04 18:05:00 CST PARSELOG: statement: SELECT attnotnull FROM
pg_catalog.pg_attribute WHERE attrelid = $1 AND attnum = $2
2005-04-04 18:05:00 CST PARSELOG: statement: SELECT def.adsrc FROM
pg_catalog.pg_class c JOIN pg_catalog.pg_attribute a ON
(a.attrelid=c.oid
) LEFT JOIN pg_catalog.pg_attrdef def ON (a.attrelid=def.adrelid AND
a.attnum = def.adnum) WHERE c.oid = $1 and a.attnum = $2 AND def.adsrc
L
IKE '%nextval(%'
2005-04-04 18:05:00 CST PARSELOG: statement: SELECT attnotnull FROM
pg_catalog.pg_attribute WHERE attrelid = $1 AND attnum = $2
2005-04-04 18:05:00 CST PARSELOG: statement: SELECT def.adsrc FROM
pg_catalog.pg_class c JOIN pg_catalog.pg_attribute a ON
(a.attrelid=c.oid
) LEFT JOIN pg_catalog.pg_attrdef def ON (a.attrelid=def.adrelid AND
a.attnum = def.adnum) WHERE c.oid = $1 and a.attnum = $2 AND def.adsrc
L
IKE '%nextval(%'
2005-04-04 18:05:00 CST PARSELOG: statement: SELECT attnotnull FROM
pg_catalog.pg_attribute WHERE attrelid = $1 AND attnum = $2
2005-04-04 18:05:00 CST PARSELOG: statement: SELECT def.adsrc FROM
pg_catalog.pg_class c JOIN pg_catalog.pg_attribute a ON
(a.attrelid=c.oid
) LEFT JOIN pg_catalog.pg_attrdef def ON (a.attrelid=def.adrelid AND
a.attnum = def.adnum) WHERE c.oid = $1 and a.attnum = $2 AND def.adsrc
L
IKE '%nextval(%'
2005-04-04 18:05:00 CST PARSELOG: statement: SELECT attnotnull FROM
pg_catalog.pg_attribute WHERE attrelid = $1 AND attnum = $2
2005-04-04 18:05:00 CST PARSELOG: statement: SELECT def.adsrc FROM
pg_catalog.pg_class c JOIN pg_catalog.pg_attribute a ON
(a.attrelid=c.oid
) LEFT JOIN pg_catalog.pg_attrdef def ON (a.attrelid=def.adrelid AND
a.attnum = def.adnum) WHERE c.oid = $1 and a.attnum = $2 AND def.adsrc
L
IKE '%nextval(%'
2005-04-04 18:05:00 CST PARSELOG: statement: SELECT attnotnull FROM
pg_catalog.pg_attribute WHERE attrelid = $1 AND attnum = $2
2005-04-04 18:05:00 CST PARSELOG: statement: SELECT def.adsrc FROM
pg_catalog.pg_class c JOIN pg_catalog.pg_attribute a ON
(a.attrelid=c.oid
) LEFT JOIN pg_catalog.pg_attrdef def ON (a.attrelid=def.adrelid AND
a.attnum = def.adnum) WHERE c.oid = $1 and a.attnum = $2 AND def.adsrc
L
IKE '%nextval(%'
2005-04-04 18:05:00 CST PARSELOG: statement: SELECT attnotnull FROM
pg_catalog.pg_attribute WHERE attrelid = $1 AND attnum = $2
2005-04-04 18:05:00 CST PARSELOG: statement: SELECT def.adsrc FROM
pg_catalog.pg_class c JOIN pg_catalog.pg_attribute a ON
(a.attrelid=c.oid
) LEFT JOIN pg_catalog.pg_attrdef def ON (a.attrelid=def.adrelid AND
a.attnum = def.adnum) WHERE c.oid = $1 and a.attnum = $2 AND def.adsrc
L
IKE '%nextval(%'
2005-04-04 18:05:00 CST PARSELOG: statement: SELECT attnotnull FROM
pg_catalog.pg_attribute WHERE attrelid = $1 AND attnum = $2
2005-04-04 18:05:00 CST PARSELOG: statement: SELECT def.adsrc FROM
pg_catalog.pg_class c JOIN pg_catalog.pg_attribute a ON
(a.attrelid=c.oid
) LEFT JOIN pg_catalog.pg_attrdef def ON (a.attrelid=def.adrelid AND
a.attnum = def.adnum) WHERE c.oid = $1 and a.attnum = $2 AND def.adsrc
L
IKE '%nextval(%'
2005-04-04 18:05:00 CST PARSELOG: statement: SELECT attnotnull FROM
pg_catalog.pg_attribute WHERE attrelid = $1 AND attnum = $2
2005-04-04 18:05:00 CST PARSELOG: statement: SELECT def.adsrc FROM
pg_catalog.pg_class c JOIN pg_catalog.pg_attribute a ON
(a.attrelid=c.oid
) LEFT JOIN pg_catalog.pg_attrdef def ON (a.attrelid=def.adrelid AND
a.attnum = def.adnum) WHERE c.oid = $1 and a.attnum = $2 AND def.adsrc
L
IKE '%nextval(%'
2005-04-04 18:05:00 CST PARSELOG: statement: SELECT attnotnull FROM
pg_catalog.pg_attribute WHERE attrelid = $1 AND attnum = $2
2005-04-04 18:05:00 CST PARSELOG: statement: SELECT def.adsrc FROM
pg_catalog.pg_class c JOIN pg_catalog.pg_attribute a ON
(a.attrelid=c.oid
) LEFT JOIN pg_catalog.pg_attrdef def ON (a.attrelid=def.adrelid AND
a.attnum = def.adnum) WHERE c.oid = $1 and a.attnum = $2 AND def.adsrc
L
IKE '%nextval(%'
2005-04-04 18:05:00 CST PARSELOG: statement: SELECT attnotnull FROM
pg_catalog.pg_attribute WHERE attrelid = $1 AND attnum = $2
2005-04-04 18:05:00 CST PARSELOG: statement: SELECT def.adsrc FROM
pg_catalog.pg_class c JOIN pg_catalog.pg_attribute a ON
(a.attrelid=c.oid
) LEFT JOIN pg_catalog.pg_attrdef def ON (a.attrelid=def.adrelid AND
a.attnum = def.adnum) WHERE c.oid = $1 and a.attnum = $2 AND def.adsrc
L
IKE '%nextval(%'

---------- Forwarded message ----------
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Apr 4, 2005 11:49 PM
Subject: Re: [PERFORM] 8.0.1 performance question.
To: alvin.yk@gmail.com
Cc: pgsql- performance@postgres
ql.org

<alvin.yk@gmail.com> writes:
> As a result, I modified log_statement to all. Without my application
> doing anything, I see statements below being executed non-stop. Who
> is triggering these statemetns? Is this normal? What am I doing
> wrong?

> 2005-04-04 18:05:00 CST PARSELOG: statement: SELECT attnotnull FROM
> pg_catalog.pg_attribute WHERE attrelid = $1 AND attnum = $2
> 2005-04-04 18:05:00 CST PARSELOG: statement: SELECT def.adsrc FROM
> pg_catalog.pg_class c JOIN pg_catalog.pg_attribute a ON
> (a.attrelid=c.oid
> ) LEFT JOIN pg_catalog.pg_attrdef def ON (a.attrelid=def.adrelid AND
> a.attnum = def.adnum) WHERE c.oid = $1 and a.attnum = $2 AND def.adsrc
> L
> IKE '%nextval(%'

Better ask about that on pgsql-jdbc. I suppose this is the trace of the
JDBC driver trying to find out column metadata ... but if it's failing
to cache the information that's a pretty serious performance hit.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

alvin.yk@gmail.com

2005-04-04, 8:04 pm

Thank you for the quick response. To help me debug what's happening,
can you tell me what's the difference between the 7.4 and 8.0 jdbc
drivers in this regard? Is this something that is newly introduced in
8.0? Or is this something that has always been happening?

Thanks.

On Apr 5, 2005 12:15 AM, Kris Jurka <books@ejurka.com> wrote:
>
>
> On Tue, 5 Apr 2005 alvin.yk@gmail.com wrote:
>
>
> These are the results of ResultSetMetaData.isNullable() and
> isAutoIncrement(), which your code is apparently calling. The results of
> these calls are cached on a per ResultSet data. We have discussed
> caching them at a higher level, but couldn't find a way to know when to
> flush that cache.
>
> Kris Jurka
>

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Sponsored Links