ide me how to catch the root cause?
Thanks in Advance!
Regards
Sekhar.
--
View this message in context:
http://apache-database.10148.n7.nabble.com/Performance-issue-with-same-index-name-in-multiple-schemas-tp145507p145580.html
Sent from the Apache Derby Users mailing list archive at Nabble.com.
Den 05.02.2016 13.22, skrev kosurusekhar:
> Hi All,
>
> We are having three schemas with almost same table structure, indexes,
> queries, stored procedures in one database. But in one schema we are facing
> some performance issue. We are having same index names and table names i
Hi All,
We are having three schemas with almost same table structure, indexes,
queries, stored procedures in one database. But in one schema we are facing
some performance issue. We are having same index names and table names in
all schemas. In another schemas it is running without any problem
in one schema we are facing
> some performance issue. We are having same index names and table names in
> all schemas. In another schemas it is running without any problem. In one
> schema with basic load only application is becoming slow.
>
> Is there any relationship with table names a
Dear Derby
Could you tell me how tuning the performance issue?
This is running sample query to fetch data from Derby database
On my dual-core XP x-32 laptop the Corporate Overview takes 406(ms).
But we saw on the dual quad core it took 22973 (ms).
I don't know why the performance became bad
/2011 04:09, QA Wang Yang a écrit :
Dear Derby
Could you tell me how tuning the performance issue?
This is running sample query to fetch data from Derby database
On my dual-core XP x-32 laptop the Corporate Overview takes 406(ms).
But we saw on the dual quad core it took 22973 (ms).
I don't
a better memory usage.
(Also the max heap size must fit in physical memory, otherwise the swap
on disk could kill perfs.)
Le 03/06/2011 04:09, QA Wang Yang a écrit :
Dear Derby
Could you tell me how tuning the performance issue?
This is running sample query to fetch data from Derby
QA Wang Yang yang.w...@support.jinfonet.com writes:
Dear Derby
Could you tell me how tuning the performance issue?
This is running sample query to fetch data from Derby database
On my dual-core XP x-32 laptop the Corporate Overview takes 406(ms).
But we saw on the dual quad core it took
Harshad harshad...@gmail.com writes:
Thanks Mike Kristian for the tips on indexes.
Creating an index on multiple columns in my DB does indeed speed up
the original query, so Yay!
It would have been even cooler if I could just declare that
combination of two columns will be unique, rather
Thanks Mike Kristian for the tips on indexes.
Creating an index on multiple columns in my DB does indeed speed up the
original query, so Yay!
It would have been even cooler if I could just declare that combination of two
columns will be unique, rather than create an index (with its associated
Rick Hillegas wrote:
I would have thought that the DISTINCT is not redundant and actually
allows for the transformation into a normal join.
I think that, for instance, a problem arises when there are M tuples in
PROVIDES with name='Fred' but there are M distinct ids in those
tuples. In
Hi Harshad,
Some comments inline...
Harshad wrote:
Rick Hillegas wrote:
Depending on your data, the two queries could return different results,
so Bryan's faster query is not a transformation which Derby would
perform automatically.
Oh yes! Although my data ensures that the
query is processed, the engine may
choose a different index.
HTH
-Mike
-Original Message-
From: news [mailto:n...@ger.gmane.org] On Behalf Of Harshad
Sent: Tuesday, December 16, 2008 11:20 PM
To: derby-user@db.apache.org
Subject: Re: Performance issue of derby using JDBC
Rick
.
Regards,
--
Kristian
HTH
-Mike
-Original Message-
From: news [mailto:n...@ger.gmane.org] On Behalf Of Harshad
Sent: Tuesday, December 16, 2008 11:20 PM
To: derby-user@db.apache.org
Subject: Re: Performance issue of derby using JDBC
[ snip ]
Rick Hillegas wrote:
Depending on your data, the two queries could return different results,
so Bryan's faster query is not a transformation which Derby would
perform automatically.
Oh yes! Although my data ensures that the subquery would return distinct
results, Derby wouldn't know about
Hi all,
I am new to Derby and database programming in general. This is my first
real-world setup, and I am getting horrifying performance from my application.
(The code is available at http://code.google.com/p/jamun/ )
It is one particular query that is causing me major worry. It is a simple
Harshad wrote:
These seem to have paid off; the actual query time
(statement.executeQuery) is pretty fast : about 1 or 2 milliseconds.
But reading from the resultSet using APIs such as getString, getLong,
takes about 250 ms or more!!
Forgot to mention; the query usually (99%) results in
Harshad wrote:
Harshad wrote:
These seem to have paid off; the actual query time
(statement.executeQuery) is pretty fast : about 1 or 2 milliseconds.
But reading from the resultSet using APIs such as getString, getLong,
takes about 250 ms or more!!
Forgot to mention; the query usually (99%)
Harshad wrote:
Harshad wrote:
These seem to have paid off; the actual query time
(statement.executeQuery) is pretty fast : about 1 or 2 milliseconds.
But reading from the resultSet using APIs such as getString, getLong,
takes about 250 ms or more!!
Forgot to mention; the query
Hi Emmanuel,
Emmanuel Cecchet wrote:
Are you using getString(columnName) or getString(1) to access the
result? Some databases only fetch ResultSetMetaData (including column
names) when it needs them. Using the column index can dramatically improve
performance. I am not sure if this is the
Hi Kristian,
The entire code is available at http://code.google.com/p/jamun/.
It is written in scala, which might not be familiar to all. I am posting below
some snippets that might help.
Kristian Waagan wrote:
I think you'll have a better chance of getting any answers if you
provide more
Harshad wrote:
select name,version,release,time from PKG where PKG.id in (select id from
PROVIDES where name = ?),
What happens if you run this statement instead:
select pkg.name,pkg.version,pkg.release,pkg.time from pkg, provides
where pkg.id = provides.id and provides.name = ?
Bryan Pendleton wrote:
Harshad wrote:
select name,version,release,time from PKG where PKG.id in (select id
from PROVIDES where name = ?),
What happens if you run this statement instead:
select pkg.name,pkg.version,pkg.release,pkg.time from pkg, provides
where pkg.id =
Harshad wrote:
Bryan Pendleton wrote:
Harshad wrote:
select name,version,release,time from PKG where PKG.id in (select id
from PROVIDES where name = ?),
What happens if you run this statement instead:
select pkg.name,pkg.version,pkg.release,pkg.time from pkg, provides
.
The performance issue is still open, although I have a theory that I would be
very happy if you could smash holes in or agree with.
My theory is that java on windows isnt 100% durable when making diskcommits.
That there is a cache or buffer somwhere ( os/controller/disk ) that doesn't
get flushed
Jonas Ahlinder wrote:
We would be willing to share the code.
What would be the best way to do this ?
Probably the best thing to do is to open up a Jira issue and attach the
code.
See http://db.apache.org/derby/DerbyBugGuidelines.html
Thanks
Kathey
: Re: performance issue
I have tried running more threads, and it does seem to give
better performance, but the current state of the client
doesnt really allow for reliable testresults.
With autocommit on, and with the disk running 100% usage
( and quite a bit of wait queue at least on Linux ) do
Hi.
We are developing a function to store session information, for use in a HA
environment.
However we are not reaching the throughput we want.
Since its for persistance, we need to do autocommit on all operations.
The Table has two indexes and a blob of data.
The first index is a char(20) and
Hello, speed depends also on JVM. What version and JVM parameters are you using?
On 10/16/08, Jonas Ahlinder [EMAIL PROTECTED] wrote:
Hi.
We are developing a function to store session information, for use in a HA
environment.
However we are not reaching the throughput we want.
Since its
Jonas Ahlinder [EMAIL PROTECTED] writes:
The first issue is that on a desktop machine ( running vista ) with
two 7.2k rpm sata disks I get over 900 tps, while on a server (
running RHEL 5 ) and two 15k rpm sas disks, I get around 250 tps.
Could it be that the desk top machine has disk caching
The first issue is that on a desktop machine ( running vista ) with
two 7.2k rpm sata disks I get over 900 tps, while on a server (
running RHEL 5 ) and two 15k rpm sas disks, I get around 250 tps.
Is your benchmark client multi-threaded? Or single-threaded?
During the run(s) are your
To: Derby Discussion
Subject: Re: performance issue
Jonas Ahlinder [EMAIL PROTECTED] writes:
The first issue is that on a desktop machine ( running vista ) with
two 7.2k rpm sata disks I get over 900 tps, while on a server (
running RHEL 5 ) and two 15k rpm sas disks, I get around 250 tps.
Could
seems rather
wierd to me, but i guess its mostly waiting for IO.
From: Bryan Pendleton [EMAIL PROTECTED]
Sent: Thursday, October 16, 2008 5:43 PM
To: Derby Discussion
Subject: Re: performance issue
The first issue is that on a desktop machine ( running vista
, October 16, 2008 4:23 PM
To: Derby Discussion
Subject: Re: performance issue
Hello, speed depends also on JVM. What version and JVM parameters are you
using?
On 10/16/08, Jonas Ahlinder [EMAIL PROTECTED] wrote:
Hi.
We are developing a function to store session information, for use in a HA
I have tried running more threads, and it does seem to give
better performance, but the current state of the client
doesnt really allow for reliable testresults.
With autocommit on, and with the disk running 100% usage
( and quite a bit of wait queue at least on Linux ) do
you think
transactions per disk write.
--
Øystein
From: Bryan Pendleton [EMAIL PROTECTED]
Sent: Thursday, October 16, 2008 5:43 PM
To: Derby Discussion
Subject: Re: performance issue
The first issue is that on a desktop machine ( running vista ) with
two 7.2k rpm
Piet Blok wrote:
There is something else that I was wondering about. You may have noticed
the SIZE and CRC column in my blob table together with the UNIQUE
constraint. Obviously, I want to prevent duplicate blob's. What happens if
I add a UNIQUE constraint on the blob data itself? Would it
-Original Message-
From: Piet Blok [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 12, 2006 12:46 AM
To: Derby Discussion
Subject: Strange performance issue with BLOB's
Hi all,
When experimenting with BLOB's I ran into a performance issue
that I cannot completely explain
issues like this a lot is made much more obvious
if you can include the query plan of the 2 queries.
Piet Blok wrote:
Hi all,
When experimenting with BLOB's I ran into a performance issue
that I cannot completely explain, but it could be a bug.
Given the following table:
CREATE TABLE BLOB_TABLE
Ewww!
Ok, so that will kill your performance.
[More below]
-Original Message-
From: Mike Matrigali [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 12, 2006 12:40 PM
To: Derby Discussion
Subject: Re: Strange performance issue with BLOB's
I think the following is what is going
Hi all,
When experimenting with BLOB's I ran into a performance issue
that I cannot completely explain, but it could be a bug.
Given the following table:
CREATE TABLE BLOB_TABLE (
BLOB_ID BIGINT NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 1,
INCREMENT BY 1),
BLOB_SIZE BIGINT NOT NULL
Hi Frederic,
This looks like a bug. I have logged bug 649 to track this issue. Thanks
for the detailed test case.
Regards,
-Rick
Frederic MOREAU wrote:
Hello,
The optimizer does not take my indexes into account when I do a select
on a 'UNION ALL' type of view ; therefore, table scans
42 matches
Mail list logo
