[OPTIMIZER] Optimizer timeout for subqueries?

. Does anyone out there know if this is a safe change? I would appreciate any feedback/advice here. If I don't hear any objections, I'll file a sub-task to DERBY-805 for this issue and post the above patch there. Many thanks in advance to anyone who might have input/feedback here. Army

Re: [OPTIMIZER] Optimizer timeout for subqueries?

Army wrote: This hasn't really been an issue to date because the best plan chosen by the subquery is typically independent of the outer query's current permutation--with the exception of outerCost, which is passed in from the outer query and is factored into the subquery's cost estimates

Re: compiling XML.java in Java 1.5

questions? Army

Re: [jira] Updated: (DERBY-815) Prevent unneeded object creation and excessive decoding in parseSQLDTA_work()

Army wrote: Dyre Tjeldvoll (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-815?page=all ] Dyre Tjeldvoll updated DERBY-815: - Attachment: derby-815_2.diff derby-815_2.stat derbyall_report_2.txt New patch

Re: [jira] Updated: (DERBY-815) Prevent unneeded object creation and excessive decoding in parseSQLDTA_work()

for your patience, Army

Re: [OPTIMIZER] OptimizerImpl best plans for subqueries?

Army wrote: Okay, so maybe that'not as clear as I'd like it to be. However, when I post these changes to DERBY-805 (as Phase 1 v2), I will also update the DERBY-805 document to include this description and a walk-through example showing how it's all supposed to work. I just attached the new

[OPTIMIZER] OptimizerImpl best plans for subqueries?

/reactions/feedback/corrections at all would be greatly appreciated... Thanks, Army

Re: [jira] Commented: (DERBY-805) Push join predicates into union and other set operations. DERBY-649 implemented scalar (single table) predicate pushdown. Adding join predicate push down could improv

to push predicates containing complex expressions, that's another enhancement of its own. I won't be doing that with my DERBY-805 changes. Thanks again--I can't say that enough--for reading the document. It's a huge one and I'm grateful for your time and feedback. Army

Re: XMLPARSE usage?

pointers... Army P.S. In case you're interested, I see the following results when using the classes directory. Note that the changes I hope to make for the 10.2 release will catch the class not found type of exceptions and print something more friendly. In the meantime, though: Sun 1.3

[OPTIMIZER] Proposal for pushing join predicates into Unions posted to DERBY-805.

this document and provide feedback, direction, or suggestions, I would be grateful. As I myself am still trying to learn all the subtleties of Derby optimization, the more feedback I get, the better... Thanks, Army

Re: [OPTIMIZER] Proposal for pushing join predicates into Unions posted to DERBY-805.

the scoped predicates for re-use, so that we don't end up re-scoping the same predicate for the same children for every permutation. Army

Re: [jira] Commented: (DERBY-761) The reserved words list in the reference manual doesn't look uptodate

category as D and T. They're for timestamp, date, and time, respectively. So whatever happens to D and T should probably (I assume, having not investigated further) also occur for TS. I.e. if you're going to remove D and T, it seems (to me) that you should probably remove TS, as well...? Army

Re: Paging Lance: format of empty result set

column is expected, etc. etc. can cause existing applications a lot of problems--see DERBY-107. Our JDBC tests might not catch it, but my past experience is that ODBC applications (esp. Microsoft ones like Access) will throw a fit if something is even slightly off... Army

Re: [VOTE] Bryan Pendleton as a committer

Kathey Marsden wrote: This vote is for establishing Bryan Pendleton as a committer for Derby. Please vote +1 if you approve of Bryan as a committer. +1 Army

Re: [jira] Commented: (DERBY-815) Prevent unneeded object creation and excessive decoding in parseSQLDTA_work()

think it might be helpful for future developers if the new code contained some additional explanatory comments... Army

Re: [jira] Updated: (DERBY-491) Protocol exception when Network Server tries to return ~32K of data or greater in a result set for a Java stored procedure.

-491 could be _either_ a protocol exception or a hang, depending on the situation), I think that'd be useful. Not obligatory, but useful... Thanks for your patience with my picking, Army

Re: [jira] Commented: (DERBY-713) CLONE - Query optimizer should not make poor choices when optimizing IN and WHERE clauses

for people to see what's going on. Otherwise, I myself am not quite clear on what is actually happening with the scenario you describe, so it's hard to offer any suggestions... Army

Re: [jira] Commented: (DERBY-754) Push ON clause predicates down when optimizing SELECT queries.

feedback... Army

Re: Optimizing subqueries [ Was: Re: VTI, Indexed Lookup and the Query Optimizer ]

for sub-optimal performance, because it disallows hash joins where they could potentially be useful. Thanks for your patience with my questions on this topic; I'm just trying to get a grasp on how this all is supposed to work... Army

Re: [jira] Updated: (DERBY-125) Network Server can send DSS greater than 32K to client, which breaks DRDA protocol.

Army wrote: - after considering my explanation of the bug, do you have an idea of a better way to write a test for it? If not, should I just remove the DERBY-125 test from prepStmt.java? Not yet; I'll have to think about this some more. I have just posted a starting point for a test

Re: VTI, Indexed Lookup and the Query Optimizer

Satheesh Bandaram wrote: Army wrote: So if we have a subquery, in which case childResult will (or least can) be a SelectNode, the fact that SelectNode is NOT an instance of Optimizable means that this method will return false and the optimizer won't ever consider a hash join when the inner

Re: VTI, Indexed Lookup and the Query Optimizer

understanding. Is there a different area that you can think of where flattening should be occuring? Can you give more info about where that flattening needs to be done? BTW, in your example the subquery contains a Cartesian product. Is that intentional? Just an example ;) Army

Re: VTI, Indexed Lookup and the Query Optimizer

? The reason I ask is because I started playing around with making the optimizer consider hash joins for subqueries, and I have made good progress in that area. Before I go too far, though, I'm wondering what it is that I'm missing--i.e. why was this disabled? Anyone know? Army

Re: [jira] Updated: (DERBY-125) Network Server can send DSS greater than 32K to client, which breaks DRDA protocol.

causing damage. I will try this out and see what happens. In the meantime, thanks again for being so thorough with all of this. I'll post again when I have further feedback to give... Army

Re: [jira] Updated: (DERBY-125) Network Server can send DSS greater than 32K to client, which breaks DRDA protocol.

, sounds good. Army

Re: [jira] Updated: (DERBY-125) Network Server can send DSS greater than 32K to client, which breaks DRDA protocol.

Army wrote: Bryan Pendleton updated DERBY-125: -- Attachment: changes2.html svn-dec_28_2005.diff [ snip ] I think these changes are now fully ready for review. Please let me know your comments as I am very interested to hear what you

Re: [jira] Commented: (DERBY-649) Useful indexes not used in UNION ALL

is always an quality node, it is not based upon the type being pushed. [ snip code replacement ] I'm far from an optimizer expert, but this change makes sense to me and appears to fulfill the copy this predicate notion that this block of code is dealing with. For what that's worth, Army

Re: Is it possible that DERBY-491 and DERBY-614 are related?

of the excellent work, Army

Re: Is it possible that DERBY-491 and DERBY-614 are related?

Bryan Pendleton wrote: Hi Bryan, This issues are related to DSS chaining which is something separate than DERBY-614. Army made a great Wiki page on the subject. http://wiki.apache.org/db-derby/DssProtocolErrors Hi Kathey, thank you very much. I will go read Army's page to learn more

Re: [jira] Commented: (DERBY-499) Expose BOOLEAN datatype to end users

= 1001; But it'd be best to leave the others off. I'll add my choice of XML ids as part of my XML patch, and other people who implement other types can add the appropriate ids with their patches, as well. Army

Re: [jira] Commented: (DERBY-499) Expose BOOLEAN datatype to end users

Army wrote: I'll add my choice of XML ids as part of my XML patch, and other people who implement other types can add the appropriate ids with their patches, as well. That is, until DRDA is updated to define the correct values, at which point the temporary values will all have to change

Re: [jira] Updated: (DERBY-499) Expose BOOLEAN datatype to end users

()? The API for that method says: Returns the fully-qualified name of the Java class whose instances are manufactured if the method ResultSet.getObject is called to retrieve a value from the column. So should a call to that method fail, too? Army

Re: [jira] Updated: (DERBY-499) Expose BOOLEAN datatype to end users

by this method (emphasis is my own). Then we'd at least be returning a valid JDBC 3.0 class name. When JDBC 4.0 support is available, changing to java.sql.SQLXML seems okay to me; i.e. there wouldn't be any compatibility problems there, would there? Army

Re: New features for next release .... (Was: Grant and Revoke ... DERBY-464...)

versions are substituted in)? Army

Re: [jira] Commented: (DERBY-506) Implement Statement.setQueryTimeout in the Client Driver

$TestFailedException: fetch did not time out. Highest execution time: 7000 ms In other words, the call to SET QUERY_TIMEOUT failed with a syntax error and was ignored, and thus the statement never timed out. Does that sound correct? Army

Re: Derby-573 - optimizer overrides changes to metadata.properties and upgrade

think. But all of that is based on my examination of the metadata codepath; if I've overlooked or oversimplified, people should feel free to correct me. Hopefully that's more helpful than confusing, Army

Re: Derby-573 - optimizer overrides changes to metadata.properties and upgrade

Satheesh Bandaram wrote: Thanks Army for the good description... But I do think there are SOME metadata calls that are stored in the database... Yes, you're absolutely right. Just after I sent that last email, I realized one other check that I should have done before clicking send. I tried

Re: New features for next release .... (Was: Grant and Revoke ... DERBY-464...)

Rick Hillegas wrote: Here are the datatypes I want to add, re-enable, or extend in the 10.2 timeframe: [ snip ] SQLXML How would this (the SQLXML type) differ from the existing XML type available as of 10.1.1 (DERBY-334)? Army

Re: New features for next release .... (Was: Grant and Revoke ... DERBY-464...)

the way. Thanks for the info, Army

[SPEC] XML Enhancements.

and provide any feedback, that'd be great. Thanks, Army

Re: [Derby-573]Optimizer overrides and metadata.properties files

== '\n')) break; } The if statement assumes a slash indicates the end of the line, but as Mamta pointed out, that's not true. This logic needs to fixed to do the correct thing. I'll look into it if no one else already is... Army

Re: [jira] Updated: (DERBY-675) Build-time processing of metadata.properties file handles slashes incorrectly.

of a reason, Yes, it would be safer to use standarad Java character reading classes. I'll make that change and post a patch soon. Army

Re: [jira] Commented: (DERBY-522) ERROR X0Y79 raised when adding comments using -- before sql queries with Network Client

://svn.apache.org/repos/asf/db/derby/code/trunk Is that acceptable? If not, what are my alternatives? Army

Re: [jira] Commented: (DERBY-522) ERROR X0Y79 raised when adding comments using -- before sql queries with Network Client

Deepa Remesh wrote: Hi Army, I have merged a patch which adds new files (DERBY-518). I did not have any problems. So I just tried your merge command and it worked for me. Here is the output I get: Daniel John Debrunner wrote: I just tried merging a different change 320762 that add

Re: lang/forUpgrade.sql failing in 10.1

file reflects the fact that the comments were NOT stripped. For the 10.1 branch, the comments are still stripped, hence the diff you're seeing. I'll post a fix for this against 10.1 shortly. Army

setNull() using Types.VARCHAR for a CLOB parameter fails in embedded mode.

should work). Can anyone confirm one way or the other? If I don't hear otherwise, I'll file a Jira issue tomorrow. Thanks, Army

Re: setNull() using Types.VARCHAR for a CLOB parameter fails in embedded mode.

Army wrote: If I attempt to call PreparedStatement.setNull() and specify Types.VARCHAR when the actual parameter type (as determined at bind time) is CLOB, Derby in embedded mode will throw an error, while Derby in client/server mode will succeed. [ snip ] Looks like the problem

Re: jdbcapi/checkDriver.java fails

directories with quoted names and thus the behavior would (hopefully) be the same across platforms... Am I correct in thinking that would resolve this issue? Army

Re: 10.1.2 update

Kathey Marsden wrote: There are currently 5 issues outstanding for 10.1.2 for Army, Knut and Jeff [ snip ] Questions Do all the open 10.1.2 bugs look like they'll make it for 10.1.2? I've unassigned myself from DERBY-500 since I'm not currently working on it and since Sunitha has

Re: [jira] Updated: (DERBY-374) Invalid URL with Derby Client when connecting to Network Server causes protocol exception.

I don't know if the results are different there. Hope I'm not being too picky... Army

Re: paging Satheesh

David Van Couvering wrote: Hi, Rick. Once this gets approval from Army and Shreyas I'll go ahead and check it in. David Rick Hillegas wrote: I have attached a new rev of the fix to bug 171. This rev addresses Army's concerns. Cheers, -Rick The new patch addresses the concerns I brought

Re: paging Satheesh

things straight in my own head... Hope that's more helpful than it is confusing/frustrating... Army

Result set holdability defined inside stored procedures is ignored by server/client

for it... Thanks for any feedback/input, Army

Re: jdbc trace

, slavic, cs); Hope that helps, Army

Re: [jira] Updated: (DERBY-407) predicatesIntoViews test failure on slow machine in Derby 10.1 branch version 201931

to comments/suggestions... Thanks, Army

Re: [jira] Created: (DERBY-438) Update triggers on tables with blob columns fail at execution time if the triggered-SQL-statement references the blob column(s).

) Should I change this to a documentation error, then? Thanks, Army

Re: [jira] Created: (DERBY-438) Update triggers on tables with blob columns fail at execution time if the triggered-SQL-statement references the blob column(s).

Daniel John Debrunner wrote: Army wrote: 1) Does this mean that we don't support _any_ triggers that are defined on tables having lob columns? Or is there some qualifier to that? Sorry, I think the qualifier should have been: accessing LOB columns of the modified table by the action

Documentation vs. Actual behavior with UNION/INTERSECT/EXCEPT

tried preparing these statements using JDBC, but they failed there with the same error. I assume this is just a documentation error, but if anyone knows differently, please speak up... Thanks, Army

Re: Documentation vs. Actual behavior with UNION/INTERSECT/EXCEPT

Ooops, copy-paste error. ij select a from t1 union select b as a from t2; I// Now it's A instead of 1. --- 1 2 The I result column name above is actually A, I just copied from the wrong window. Sorry for any confusion. Army -- Army wrote: I noticed

Re: Little adv. XML support

to the next without any changes to the app code), 3) standards-compliant (based on SQL/XML standards) I hope all of that makes sense, but if you have any further questions, please do ask... Thanks! Army

Re: [jira] Updated: (DERBY-275) Add documentation support for BY DEFAULT option, once code changes are made.

to my own personal opinion; I'm hoping that if anyone out there disagrees with any of this feedback (including you, Jeff :), s/he will speak up... Army

Re: Little adv. XML support

at #4... Thanks again for your interest in working with Derby, and I look forward to hearing from you as you work on this project. And of course, if you have questions, please do ask! Army

Re: [jira] Updated: (DERBY-373) Documentation errors in Server/Admin Guide.

: jdbc:derby:sample;createFrom=c:\mybackups\sample I think that's it; thanks for your patience, and sorry again for my incorrect/incomplete comments the first time around... Army

Re: [jira] Updated: (DERBY-373) Documentation errors in Server/Admin Guide.

for this bug have been handled now, so I give this a +1 to be committed... Army

Re: request for patch reviews

, and that the whole section on Identity column attributes might be more helpful if it was moved to the place where the actual syntax is described... *shrug* Army

[PATCH] Master update for parameterMapping.java

The attached patch updates a master/canon for the jdbcapi/parameterMapping.java test; it looks like it was inadvertently left out of svn revision 190127. Could a committer please commit? Thanks much, Army Index: java/testing/org/apache/derbyTesting/functionTests/master/DerbyNet/ver2.6

Re: [jira] Commented: (DERBY-275) Add documentation support for BY DEFAULT option, once code changes are made.

, though, that a slight dblook modification should be made for DERBY-337; I'll post a comment to that issue and that can serve as the start of a new thread... Army

Re: XML build problem

, and thanks for figuring that out... Army

Re: [jira] Commented: (DERBY-337) dblook doesn't generate SQL statements for SQL functions.

either way... Army

Re: [jira] Commented: (DERBY-319) Derby returns incorrect values for LENGTH column of DatabaseMetaData.getProcedureColumns() result set.

they are a bit odd, I'm still okay with them being there... Thanks again for the review! Army

Re: [jira] Updated: (DERBY-334) Add initial SQL support for XML datatype/functions in Derby, based on SQL/XML specs.

. Does this new XML feature require a VOTE before commit? Army

Re: [jira] Commented: (DERBY-337) dblook doesn't generate SQL statements for SQL functions.

if (returnType == null) ... But I've added comments to the IF, so I guess either is probably okay... Any preference? Thanks for the review, Army

Re: derbynetmats/DerbyNet/derbynetmats/testij fails

of the server tests. Most of the masters were correctly updated, but it looks like this one might have slipped by... Army

[PATCH] Follow-up master updates for DERBY-305

). Attached is a small patch that updates these two master files to match the changes committed with DERBY-305. Could a committer please commit? Thanks, Army Index: java/testing/org/apache/derbyTesting/functionTests/master/DerbyNet/ibm14/importExport.out

Intermittent failure with lang/errorStream.java (added w/ DERBY-205)

)... Comments? Army

Re: 10.1 release status

Andrew McIntyre wrote: Hello derby-dev, Here's the current status as we head towards a 10.1 release. [ snip ] Derby-337: dblook should generate SQL statements for SQL functions - any takers? Unless anyone objects, I'll volunteer to look at this one... Army

[PATCH] Add if (SanityManager.DEBUG) around two unprotected uses of SanityManager.

is a very simple patch that modifies the following two files by adding an if (SanityManager.DEBUG) block around the code in question: org/apache/derby/iapi/sql/dictionary/ColumnDescriptor.java org/apache/derby/impl/store/raw/data/FileContainer.java Could a committer please commit? Army Index: java

Re: [jira] Updated: (DERBY-337) dblook doesn't generate SQL statements for SQL functions.

are not. And according to the documentation, they're not the same. What this JIRA entry is asking for is new functionality, as opposed to a fix for broken functionality. Okay, okay, it's a technicality. But still... *shrug* Army

Re: [jira] Resolved: (DERBY-194) getPrecision() on TIME and TIMESTAMP is zero

Samuel Andrew McIntyre (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-194?page=all ] Samuel Andrew McIntyre resolved DERBY-194: -- Resolution: Fixed Patch was committed with svn revision 179839. Could Army or George please

Re: [jira] Updated: (DERBY-230) Schema already exists when creating a table

: ConcurrentImplicitCreateSchema jdk1.4.2_07 2005-06-04 07:34:15 *** No master file was found. Test Failed. *** End: ConcurrentImplicitCreateSchema jdk1.4.2_07 2005-06-04 07:34:16 *** Can you (or some other committer) look at this? Army

Re: [jira] Commented: (DERBY-334) Add initial SQL support for XML datatype/functions in Derby, based on SQL/XML specs.

to types.iapi, and 2) is simplified to just worry about a single XML (UTF-8 based) implementation. Thanks much for the feedback! Army

[PATCH] DERBY-319: Derby returns incorrect values for LENGTH column of DatabaseMetaData.getProcedureColumns() result set

/en-us/odbc/htm/odbctransfer_octet_length.asp I have run derbyall on a Windows 2000 machine with Sun JDK 1.4.2 and all tests passed. Could a committer please review/commit this patch? Thanks, Army

Re: [jira] Commented: (DERBY-334) Add initial SQL support for XML datatype/functions in Derby, based on SQL/XML specs.

implementation can deal with it ;) Otherwise, I'm certainly open to ideas on how else to get this info without using the SQL layer...? Army

Re: [jira] Commented: (DERBY-334) Add initial SQL support for XML datatype/functions in Derby, based on SQL/XML specs.

without running derbyall is a bit too risky, since my changes weren't just to the new XML files). Army

Re: [jira] Updated: (DERBY-230) Schema already exists when creating a table

be affected. Unless someone objects (if you do, say so now!), I vote +1. Could a committer please commit? Thanks, Army

[PATCH] DERBY-121: Network Server reading blob/clob data size.

out there for review right now, but since this patch (namely, the new largeData suite) could have an impact on future tests/patches in this area, I'm hoping some people can review this and let me know if I need to change anything... Feedback is appreciated, Army M java\drda\org\apache

Re: looking for opinions on reasonable hardware requirements for tests in standard derby suite

... Army

Re: [jira] Updated: (DERBY-121) Network Server reading blob/clob data size

change the bug description to have the correct size instead of 64K? Yep, will do. Army

Re: [jira] Updated: (DERBY-230) Schema already exists when creating a table

be on the assumption that this was removed. If it's intentional, then can you tell me briefly what this is doing? Thanks for your patience, Army

Re: DERBY-318(Re: DERBY-308 just be done and .... (Re: [jira] Updated: (DERBY-308) Modify dblook to support GENERATED BY DEFAULT AS IDENTITY))

think you can go ahead and do things the way you think is best. So please feel free to make the change as you prefer, and to post the patch to the list so we can proceed. Thanks! Army

[PATCH] DERBY-194: Precision/scale for Derby datetime values.

updates in the patch. The svn stat output is attached to this email, along with the patch itself. Could someone review/commit? Many Thanks, Army M java\engine\org\apache\derby\impl\jdbc\metadata.properties M java\engine\org\apache\derby\iapi\types\DataTypeUtilities.java M java\engine

Re: Planning for a 10.1 release

at DERBY-194 and DERBY-319, which are minor metadata changes. I have patches for both, but am still in the process of running derbyall. Again, both are fairly minor and should _not_ be considered show-stoppers. Army

Re: [PATCH] (DERBY-230) Schema already exists when creating a table

like that could be done... In short, I approve of the fix, but I'm not sure the corresponding test is fully reliable. Is there any way to guarantee the test will catch a failure in this area in the future? Army

Re: DERBY-308 just be done and .... (Re: [jira] Updated: (DERBY-308) Modify dblook to support GENERATED BY DEFAULT AS IDENTITY)

...? The safest (consistent) thing to do is to return NULL for columns that are GENERATED BY DEFAULT, so I think that's what I would vote for (despite my initial email saying otherwise). But that's just me--I hope anyone who feels otherwise will post saying so... Army

Re: DERBY-308 just be done and .... (Re: [jira] Updated: (DERBY-308) Modify dblook to support GENERATED BY DEFAULT AS IDENTITY)

Oops. In that last email, replace all occurrences of DefaultNodeImpl with DefaultInfoImpl. For some reason the wrong file name was in my head. Army wrote: That said, I think returning any non-null value in DefaultNodeImpl.toString() will solve the problem The question then becomes what

Re: DERBY-308 just be done and .... (Re: [jira] Updated: (DERBY-308) Modify dblook to support GENERATED BY DEFAULT AS IDENTITY)

be safer to try to remove those characters from the patch before submitting, if that's possible...? I will file a JIRA entry for the DRDA protocol problem I mentioned above. You may want to wait until that protocol issue can be resolved before proceeding with this DERBY-308 patch... Army

Re: DERBY-308 just be done and .... (Re: [jira] Updated: (DERBY-308) Modify dblook to support GENERATED BY DEFAULT AS IDENTITY)

Army wrote: TomohitoNakayama wrote: I have just done DERBY-308. I uploaded patch just for reviewing. [snip] when I myself tried to run dblook_test_net against the server, I got a protocol exception with the GENERATED BY DEFAULT column. [snip] I will file a JIRA entry for the protocol

Re: [PATCH] Initial XML Support

Army wrote: Please find attached the patch for adding initial XML support to Derby. [ snip patch description ] I ran the derbylang suite with Sun JDK 1.4.2 on Windows and all of the tests passed. I haven't had a chance to run the full derbyall suite yet, but plan to do that tonight. I

Re: [jira] Updated: (DERBY-230) Schema already exists when creating a table

Army wrote: I looked at this patch and it seems right, but I'd want to be able to run your new test before giving my full +1. That said, I'm unable to run the test because I can't get the patch to apply to my codeline. Could you perhaps re-generate the patch with the latest codeline

Re: [jira] Updated: (DERBY-230) Schema already exists when creating a table

files in derbynetmats.runall will be run as part of derbynetclientmats, as well. Thus, if you add your new test to derbynetmats.runall, you will NOT have to add it to derbynetclientmats.runall; it will be included by recursion. Hope that helps, Army

<    1   2   3   4   >