Large page cache kills initial performance
--
Key: DERBY-704
URL: http://issues.apache.org/jira/browse/DERBY-704
Project: Derby
Type: Bug
Components: Services, Performance
Versions: 10.1.2.2, 10.1.3.0, 10.2.0.0,
[ http://issues.apache.org/jira/browse/DERBY-704?page=all ]
Knut Anders Hatlen updated DERBY-704:
-
Attachment: DERBY-704.diff
derbyall_report.txt
Attached patch and report from running derbyall (no tests failed).
The patch modifies
Suresh Thalamati wrote:
Andreas Korneliussen wrote:
Mike Matrigali wrote:
snip
I would think there are multiple ways of adressing this issue:
1 We could make the store graciously handle the situation if the
RowLocation points to a deleted+purged row, by returning false if the
[ http://issues.apache.org/jira/browse/DERBY-704?page=all ]
Knut Anders Hatlen updated DERBY-704:
-
Attachment: throughput.png
cpu-usage.png
Attached graphs showing the throughput and CPU usage running with and
without the patch. The
Mike Matrigali wrote:
i get confused when speaking about isolation level, update/read only
result sets, and underlying sql query of the result set. I don't
know if one scrollable result sets are dependent on some sort of
isolation level.
With respect to straight embedded server execution of
[
http://issues.apache.org/jira/browse/DERBY-704?page=comments#action_12357574 ]
Knut Anders Hatlen commented on DERBY-704:
--
Sorry, I forgot the output from svn stat.
M java/engine/org/apache/derby/impl/services/cache/Clock.java
Large page
Mike Matrigali wrote:
null pointer is a bug, please report as a separate JIRA,not sure
what is going on. Note that while it is convenient for testing
purposes to use the SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE
to cause the purging, purging of rows can happen at any time
after a delete has been
Hi,
Daniel == Daniel John Debrunner [EMAIL PROTECTED] wrote:
Daniel This would be great to be on a wiki page, including links to the Jira
Daniel entries with the functional specs. I'm losing track of which functional
Daniel specs are out there, just saw in some reply that Dag has posted a
[
http://issues.apache.org/jira/browse/DERBY-587?page=comments#action_12357595 ]
Rick Hillegas commented on DERBY-587:
-
I have successfully built this patch under jdk1.4 and jdk1.6. For me derbyall
runs cleanly under jdk1.4. Under jdk1.6 the new jdbc4
Daniel John Debrunner wrote:
...
How much demand for this type, as you've described is there? Are many
Java applications using byte for fields? My guess would have been that
any requests for TINYINT would have been due to existing database
applications.
I think Lance is right: we can see
[
http://issues.apache.org/jira/browse/DERBY-506?page=comments#action_12357597 ]
Oyvind Bakksjo commented on DERBY-506:
--
Sendingjava/client/org/apache/derby/client/am/PreparedStatement.java
Sending
[ http://issues.apache.org/jira/browse/DERBY-506?page=all ]
Oyvind Bakksjo resolved DERBY-506:
--
Resolution: Fixed
Had to disable some testing because of DERBY-694
Implement Statement.setQueryTimeout in the Client Driver
[ http://issues.apache.org/jira/browse/DERBY-506?page=all ]
Oyvind Bakksjo closed DERBY-506:
Implement Statement.setQueryTimeout in the Client Driver
Key: DERBY-506
URL:
Re-enable test which was disabled in DERBY-506 commit
-
Key: DERBY-705
URL: http://issues.apache.org/jira/browse/DERBY-705
Project: Derby
Type: Test
Components: Test
Reporter: Oyvind Bakksjo
Priority:
Hi Mike,
It appears that RowLocations are stable under some combinations of
isolation levels and lock granularities but that, in general, a
RowLocation isn't guaranteed to be stable even for the duration of a
statement. Is there some other, more stable handle on a heap row? By
more stable I
[
http://issues.apache.org/jira/browse/DERBY-47?page=comments#action_12357601 ]
Kevin Hore commented on DERBY-47:
-
I have also found this issue to be a problem and would like to know whether
there are any plans to fix it?
What follows is a copy of
Not really.
I don't think even a unique key constraint meets the requirements,
as the row can be deleted and a different row can be created.
Rick Hillegas wrote:
Hi Mike,
It appears that RowLocations are stable under some combinations of
isolation levels and lock granularities but that, in
Hi all,
has anyone tried to build the Derby jars based on the 10.1.2.1 (10.1.2
Release Candidate #2) source code archive? (We are supposed to be able
to do this, right?)
I downloaded db-derby-10.1.2.1-src.tar.gz from
http://people.apache.org/~kmarsden/derby10.1.2.1.330608/ and extracted
the
I like Lance's suggestion and would like to propose it as a general
policy. I think that this will handle Army's XML work as well as the
other new 10.2 datatypes:
If you add a new datatype to a server release (e.g., BOOLEAN or XML),
then you must specify the following:
1) A legacy datatype
[
http://issues.apache.org/jira/browse/DERBY-614?page=comments#action_12357583 ]
Kathey Marsden commented on DERBY-614:
--
I wanted to check in on this issue. I wanted to make sure that my comment that
it would be good to get input wasn't stalling your
Myrna van Lunteren wrote:
Hi,
I'm working on DERBY-413, trying to remove the hardcoded 'localhost' from
the tests, and found this comment and subsequent line in the test
derbynet/dataSourcePermissions_net.java:
--
if (TestUtil.isJCCFramework())
{
attrs.setProperty(driverType,4);
Hi!
Satheesh Bandaram (JIRA) wrote (2005-11-10 19:22:03):
Satheesh Bandaram commented on DERBY-699:
-
Derby needs to treat many schemas starting with SYS.. as system
schemas... like SYSCAT, SYS, SYSFUN, SYSSTAT, SYSPROC, SYSIBM,
SYSCS_DIAG,
On Nov 14, 2005, at 9:00 AM, John Embretsen wrote:
has anyone tried to build the Derby jars based on the 10.1.2.1 (10.1.2
Release Candidate #2) source code archive? (We are supposed to be able
to do this, right?)
A google search led me to a thread in the mailing list archive of
Apache
Rick Hillegas wrote:
I like Lance's suggestion and would like to propose it as a general
policy. I think that this will handle Army's XML work as well as the
other new 10.2 datatypes:
If you add a new datatype to a server release (e.g., BOOLEAN or XML),
then you must specify the following:
[
http://issues.apache.org/jira/browse/DERBY-506?page=comments#action_12357610 ]
Satheesh Bandaram commented on DERBY-506:
-
Thanks for the useful and good patch!! I did a quick review of the code and
have couple of comments:
1) Is there any
Rick Hillegas wrote:
I like Lance's suggestion and would like to propose it as a general
policy. I think that this will handle Army's XML work as well as the
other new 10.2 datatypes:
If you add a new datatype to a server release (e.g., BOOLEAN or XML),
then you must specify the following:
I thought Rick's suggestion of adding the UNSIGNED keyword was a good
solution -- we can get the best of both worlds...
David
Francois Orsini wrote:
Since Sybase, MySQL and MS SQL Server have had support for UNSIGNED
TINYINT for many years (at least for 2 of them), offering support for an
There appear to be definite improvements here in terms of the
consistency of throughput and CPU usage.
Are the regular massive spikes in throughput and CPU usage related to
the issues that Oystein was raising about checkpointing?
Thanks,
David
Knut Anders Hatlen (JIRA) wrote:
[
Monday, November 14, 2005, 7:33:51 PM CET, Andrew McIntyre wrote:
On Nov 14, 2005, at 9:00 AM, John Embretsen wrote:
has anyone tried to build the Derby jars based on the 10.1.2.1 (10.1.2
Release Candidate #2) source code archive? (We are supposed to be able
to do this, right?)
A google
On Nov 14, 2005, at 11:52 AM, John Embretsen wrote:
I am using Subversion 1.1.4, but this should not matter in this
case, should it?
I mean, I guess it is the subversion version of the person doing
the release
packaging (in this case Kathey, right?) that matters, or am I
misunderstanding
[
http://issues.apache.org/jira/browse/DERBY-680?page=comments#action_12357621 ]
Deepa Remesh commented on DERBY-680:
By changing the above code to check for the value returned by ps.getMetaData()
, the prepared statements q10 and q11 listed in the
+1. Original argument of ease of migration from Sybase, Microsoft
servers goes for a toss with a SIGNED implementation. There are too many
issues with the current proposal. I am for making this follow closer to
current implementations, if all.
Satheesh
Francois Orsini wrote:
Since Sybase,
MM == Mike Matrigali [EMAIL PROTECTED] writes:
MM Not really.
MM I don't think even a unique key constraint meets the requirements,
MM as the row can be deleted and a different row can be created.
HeapRowLocation contains a RecordHandle which if I have understood
this correctly
David W. Van Couvering wrote:
I thought Rick's suggestion of adding the UNSIGNED keyword was a good
solution -- we can get the best of both worlds...
So more non-standard syntax? Why is it better for a SQL Server/Sybase
application to change their types to TINYINT UNSIGNED, instead of
[
http://issues.apache.org/jira/browse/DERBY-614?page=comments#action_12357630 ]
Francois Orsini commented on DERBY-614:
---
I have done a bit of reading on the subject (which was a great learning
exercise btw) and I find Brian's approach with 1) and 2)
Daniel John Debrunner wrote:
Rick Hillegas wrote:
I like Lance's suggestion and would like to propose it as a general
policy. I think that this will handle Army's XML work as well as the
other new 10.2 datatypes:
If you add a new datatype to a server release (e.g., BOOLEAN or XML),
then
Rick Hillegas wrote:
Daniel John Debrunner wrote:
Maybe replace 'you must' with 'you can'. If someone has the itch to add
a type for embedded only, then I don't think they should be forced to
make it work with old or new clients.
I'm concerned that if you can create a column, you ought
Daniel John Debrunner wrote:
David W. Van Couvering wrote:
I thought Rick's suggestion of adding the UNSIGNED keyword was a good
solution -- we can get the best of both worlds...
So more non-standard syntax? Why is it better for a SQL Server/Sybase
application to change their types
Rick Hillegas wrote:
You can also implement NOT NULL as a check contraint. Most databases
consider that to be an inefficiency which it's worth optimizing with
custom logic.
Custom logic that's defined by the SQL Standard. :-)
Dan.
On 11/14/05, Rick Hillegas [EMAIL PROTECTED] wrote:
Daniel John Debrunner wrote:David W. Van Couvering wrote:I thought Rick's suggestion of adding the UNSIGNED keyword was a goodsolution -- we can get the best of both worlds...
So more non-standard syntax? Why is it better for a SQL
At the Open Source Database Conference (http://www.opendbcon.net/) in
Frankfurt last week, MySQL AB hosted a dinner for the database speakers
and others involved in open source databases. The idea was to see how
open source databases could collaborate. Øystein Grøvlen and myself were
at the
Bernt M. Johnsen wrote:
Satheesh Bandaram commented on DERBY-699:
-
Derby needs to treat many schemas starting with SYS.. as system
schemas... like SYSCAT, SYS, SYSFUN, SYSSTAT, SYSPROC, SYSIBM,
SYSCS_DIAG, SYSCS_UTIL. It may be possible to add future
[ http://issues.apache.org/jira/browse/DERBY-704?page=all ]
David Van Couvering resolved DERBY-704:
---
Resolution: Fixed
Checked in patch, revision number 344270
bash-2.05$ svn commit
Sending
[ http://issues.apache.org/jira/browse/DERBY-689?page=all ]
Rick Hillegas updated DERBY-689:
Attachment: bug689_2.diff
bug689_2.diff further improves this suite by adding a target for running just
one combination of client/clientVM/server/serverVM. The
Hi,
Francois == Francois Orsini [EMAIL PROTECTED] wrote:
Francois Dan's argument which is mine too I believe is in respect with users
Francois migrating from Sybase/MS SQL Server apps using TINYINT to Derby - if
we
Francois provide an unsigned type by default then they don't have anything to
This is highly arguable - you say SQL is ugly as it is (which is
arguable by itself ;)) but then you think it's ok to add a non-standard
UNSIGNED keyword if we want the unsigned version which has been there
for more than 15 years at least in very well known RDBMS out there ;)
Either way is fine
[ http://issues.apache.org/jira/browse/DERBY-682?page=all ]
Deepa Remesh resolved DERBY-682:
Fix Version: 10.2.0.0
Resolution: Fixed
Resolved by svn revision 332645
Add tests for error codes for severe exceptions
[ http://issues.apache.org/jira/browse/DERBY-682?page=all ]
Deepa Remesh closed DERBY-682:
--
Add tests for error codes for severe exceptions
---
Key: DERBY-682
URL:
[
http://issues.apache.org/jira/browse/DERBY-587?page=comments#action_12357651 ]
Satheesh Bandaram commented on DERBY-587:
-
Thanks, Narayanan, for the follow up. I think only the ICLA is the pending
issue now. Jean had mentioned last time that
[
http://issues.apache.org/jira/browse/DERBY-280?page=comments#action_12357654 ]
Satheesh Bandaram commented on DERBY-280:
-
Rick, what have you decided about this patch? Would you like me to commit this?
As I mentioned, I believe, this patch
Satheesh Bandaram (JIRA) wrote:
2) What would happen if a 10.2 client tries to send a SET STATEMENT_TIMEOUT
statement to a 10.1 server? There doesn't seem to be any mechanism to prevent
unpleasant events.
I was reviewing the patch and decided to look into your question more, and I
think
[ http://issues.apache.org/jira/browse/DERBY-239?page=all ]
Suresh Thalamati updated DERBY-239:
---
Attachment: onlinebackup_3.diff
This patch adds code to support real-time online backup with unlogged
operations. A consistent backup can not be made if
52 matches
Mail list logo
