Activity
From 07/10/2020 to 08/08/2020
08/08/2020
- 06:59 AM Feature #3814: more schema metadata
- It is interesting that for some system tables the @_Field@ table contains records for fields which are not shown in t...
08/07/2020
- 05:52 PM Feature #3814: more schema metadata
- Constantin Asofiei wrote:
> Igor, please see the @TYPE_@ constants in @LegacyJavaAppserverApi@ - I think @_dtype@ is... - 05:20 PM Feature #3814: more schema metadata
- Igor, please see the @TYPE_@ constants in @LegacyJavaAppserverApi@ - I think @_dtype@ is the same. You can confirm t...
- 05:10 PM Feature #3814: more schema metadata
- Greg Shah wrote:
> Is @_field._dtype@ the same as the data-type list I've described in #3549-3 and #3549-4?
Greg,... - 04:30 PM Feature #3814: more schema metadata
- Is @_field._dtype@ the same as the data-type list I've described in #3549-3 and #3549-4?
- 04:22 PM Feature #3814: more schema metadata
- Based on the analisys of the content of the @_Field@ table in the large customer database (12000+ records in this tab...
- 09:49 AM Support #4701: try to improve H2 transaction commit performance
- Please build the necessary changes. It would be best to implement this such that we can set a flag and choose "per-u...
08/06/2020
- 11:46 AM Support #4701: try to improve H2 transaction commit performance
- Greg Shah wrote:
> What is the development effort needed to make this work? Is the meta database a problem?
At t... - 10:45 AM Support #4701: try to improve H2 transaction commit performance
- Your results in #4843 (per-user "private" @_temp@ H2 instances vs the current "global" instance approach) are very en...
08/05/2020
- 12:50 PM Feature #3814: more schema metadata
- Greg Shah wrote:
> Can you finish #3814-185 items 1-3 by Friday?
Yes, I think that it possible. If not, I will fini... - 12:47 PM Feature #3814: more schema metadata
- Can you finish #3814-185 items 1-3 by Friday?
> It is difficult to estimate the time which is required for impleme... - 12:42 PM Feature #3814: more schema metadata
- Status summary update (see #3814-135)
# Adding of the mandatory meta-tables is enforced. Working now on handling som... - 10:02 AM Support #4701: try to improve H2 transaction commit performance
- The preliminary results reported by Apache JMeter are not very promising. However, note that the used tests are pure ...
08/03/2020
- 08:00 AM Support #4701: try to improve H2 transaction commit performance
- Eric Faulhaber wrote:
> Adrian, as I understand it, your JMeter test environment can simulate heavy multi-user use, ...
08/01/2020
- 05:54 PM Support #4701: try to improve H2 transaction commit performance
- Adrian, as I understand it, your JMeter test environment can simulate heavy multi-user use, correct?
I would like ...
07/31/2020
- 11:31 AM Feature #4011: database/persistence layer performance improvements
- Ovidiu, OK, I see that these are emitted at the @Table@ annotation for the DMO interface. Before that , we had code ...
- 11:08 AM Feature #4011: database/persistence layer performance improvements
- I tried to keep as much compatibility as I was aware when I added the new annotations and even added new attributes. ...
- 10:52 AM Feature #4011: database/persistence layer performance improvements
- Ovidiu Maxiniuc wrote:
> Have you encountered this necessity in customer code?
Yes. The previous support needs to ... - 10:30 AM Feature #4011: database/persistence layer performance improvements
- Constantin,
Have you encountered this necessity in customer code?
The problem might be more complicated than ad... - 06:21 AM Feature #4011: database/persistence layer performance improvements
- Ovidiu Maxiniuc wrote:
> We are talking about two different types of 'attributes' of the temp-tables:
> * structur...
07/30/2020
- 03:50 PM Feature #4011: database/persistence layer performance improvements
- Constantin,
I replaced the last conditional from the code you posted in note-791 with... - 01:32 PM Feature #4011: database/persistence layer performance improvements
- Ovidiu Maxiniuc wrote:
> The problem with @BufferImpl.fill@ is not only in the code from 791 but in previous lines, ... - 10:20 AM Feature #4011: database/persistence layer performance improvements
- The problem with @BufferImpl.fill@ is not only in the code from 791 but in prevous lines, too.
# use of @dereference...
07/29/2020
- 05:19 PM Bug #4825: OutputTableHandleCopier dynamically defines destination temp-table
- Constantin Asofiei wrote:
> Something else we could do is to force the DMO interface to be the one from the source t... - 04:19 PM Bug #4825: OutputTableHandleCopier dynamically defines destination temp-table
- Something else we could do is to force the DMO interface to be the one from the source temp-table (to avoid building ...
- 02:36 PM Bug #4825: OutputTableHandleCopier dynamically defines destination temp-table
- Eric, I understand your POV, but at the caller's side we have a @handle@ parameter, right? In this case, we need to c...
- 02:24 PM Bug #4825: OutputTableHandleCopier dynamically defines destination temp-table
- As I was debugging an API-based regression test, I noticed we end up quite often in this code in @OutputTableHandleCo...
- 01:55 PM Bug #4825 (New): OutputTableHandleCopier dynamically defines destination temp-table
- 01:25 PM Feature #4011: database/persistence layer performance improvements
- Ovidiu, see this test:...
- 01:14 PM Feature #4011: database/persistence layer performance improvements
- The validation has changed a bit. I need more input on this. What exactly is wrong with MERGE and REPLACE fill modes?
- 01:08 PM Feature #4011: database/persistence layer performance improvements
- This code in @BufferImpl.fill@:...
07/28/2020
- 01:05 PM Feature #4055: optimize temp-table output parameter copying
- @loose-copy-mode@ sounds like a case 4 in which the index mapping for the source/target pair is not calculated by fie...
- 12:58 PM Feature #4055: optimize temp-table output parameter copying
- Greg Shah wrote:
> > There are the DATASET-related cases, for FILL and such - I haven't looked at how these can be i... - 12:42 PM Feature #4055: optimize temp-table output parameter copying
- > There are the DATASET-related cases, for FILL and such - I haven't looked at how these can be improved.
Do the D... - 11:52 AM Feature #4055: optimize temp-table output parameter copying
- Greg Shah wrote:
> In regard to case 3, I know it is not possible with table parameters of methods, so I wonder if i...
07/27/2020
- 05:54 PM Feature #4055: optimize temp-table output parameter copying
- Some thoughts about table copying. I know of at least 3 different copy scenarios:
# source and target tables are ... - 09:21 AM Support #4701: try to improve H2 transaction commit performance
- I uploaded @fwd-h2-1.4.200-20200727.jar@ to @devsrv01:/tmp/@, which includes the patch mentioned in #4701-38.
- 09:14 AM Support #4701: try to improve H2 transaction commit performance
- I found out that the transactional keyword was exploiting a vulnerability of constraints inside create table statemen...
07/25/2020
- 07:44 AM Support #4701: try to improve H2 transaction commit performance
- Moved the @Timeout trying to lock table "SYS"@ topic from #4753 here.
# The exception can appear with different st...
07/24/2020
- 01:50 PM Feature #4022: upgrade to a newer PostgreSQL release
- Also, please update the FWD docs to make it more clear where we might put it by default.
- 01:22 PM Feature #4022: upgrade to a newer PostgreSQL release
- Stanislav Lomany wrote:
> "Installation of PL/Java Base Support" documentation states that this file should be put _... - 01:19 PM Feature #4022: upgrade to a newer PostgreSQL release
- "Installation of PL/Java Base Support" documentation states that this file should be put _somewhere_ in a directory r...
- 01:07 PM Feature #4022: upgrade to a newer PostgreSQL release
- Stanislav Lomany wrote:
> The only question I have regarding installation is about this code from the customer's @bu... - 01:06 PM Feature #4022: upgrade to a newer PostgreSQL release
- The only question I have regarding installation is about this code from the customer's @build_db.xml@:...
- 08:29 PM Feature #4022: upgrade to a newer PostgreSQL release
- I've compared times for postgres 12.3 vs 9.5 and they're absolutely the same (in average). I've tested times for:
# ...
07/23/2020
- 01:52 PM Bug #4760 (Closed): new keywords added in H2 1.4.200
- 01:51 PM Bug #4760: new keywords added in H2 1.4.200
- Eric Faulhaber wrote:
> Just looked over the changes and they seem fine. Is @_rowid_@ really a reserved keyword for ... - 01:49 PM Bug #4760: new keywords added in H2 1.4.200
- Just looked over the changes and they seem fine. Is @_rowid_@ really a reserved keyword for H2? Seems an odd one.
... - 08:12 PM Feature #4022: upgrade to a newer PostgreSQL release
- > Which version of PostgreSQL are you using?
12.3
> Were you able to leverage the pre-built PL/Java binaries?
I ...
07/22/2020
- 05:20 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Eric Faulhaber wrote:
> As I think about the addition of the multiplex ID to the L1 key, it occurs to me that we h... - 05:19 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- As I think about the addition of the multiplex ID to the L1 key, it occurs to me that we have a potential memory leak...
- 04:35 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Code review 4011b/11588:
Looks good. The @buffer.isTemporary()@ check can be eliminated in the @FFC.Key@ c'tor, si... - 04:22 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- The new L1 key implemented in r11588. Please update.
- 03:09 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- I think it makes sense to encapsulate the several behaviors of the FFC that are required to be different between temp...
- 02:55 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Code review 4011b/11586:
Please see #4796-8, specifically the points about @updateLock@ and about leaking locks. T... - 02:20 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Sorry, you are right. I will prepare a patch for this.
- 02:16 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Ovidiu Maxiniuc wrote:
> Actually no.
> The temp cache for tables-tables are context local. See @FastFindCache.getI... - 02:14 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Actually no.
The cache objects for tables-tables are context local. See @FastFindCache.getInstance(boolean)@. Only t... - 02:03 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Ovidiu, the fact that you use a @dmoUid@ is not OK for temp-tables. You need to include the multiplex, too.
A @de... - 03:55 PM Feature #4022: upgrade to a newer PostgreSQL release
- Which version of PostgreSQL are you using?
Were you able to leverage the pre-built PL/Java binaries?
Any issues... - 03:40 PM Feature #4022: upgrade to a newer PostgreSQL release
- Import of the customer's data is running.
- 12:48 PM Feature #4022: upgrade to a newer PostgreSQL release
- What is the status with v12.x?
- 03:19 AM Feature #4011: database/persistence layer performance improvements
- Rev 11584 resolves all but the 2f and 3f parts of the test case in #4011-633.
07/21/2020
- 06:46 PM Feature #4022: upgrade to a newer PostgreSQL release
- If 13 is beta, don't use it. Use the latest stable released build.
- 06:24 PM Feature #4022: upgrade to a newer PostgreSQL release
- I'm not able to build the latest pljava 1.5.5 with postgresql 13 beta 2. There're compilation errors caused by incomp...
- 05:55 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- My first instinct was to pull the argument resolution forward from @executeImpl@ to @execute@, but that is a lot of r...
- 03:14 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- I found a new issue with FFC.
When we add a new result for the cache, use use the substitution array as part of th... - 02:37 AM Bug #4796: locking regression in RAQ introduced with the FFC
- Eric Faulhaber wrote:
> I had to make one change ...
This was committed as rev 11580. - 02:13 AM Bug #4796: locking regression in RAQ introduced with the FFC
- Code review 4011b/11579:
I had to make one change to get the @RecordLockContext@ directly from @RecordBuffer@, rat...
07/20/2020
- 05:15 PM Bug #4796: locking regression in RAQ introduced with the FFC
- I committed revision 11579. I am unable to test at this moment with customer application.
- 03:13 PM Bug #4796: locking regression in RAQ introduced with the FFC
- It is unfortunate that the @RecordIdentifier@ used in the FF cache and session cache is not the same as can be used f...
- 03:02 PM Bug #4796: locking regression in RAQ introduced with the FFC
- Eric Faulhaber wrote:
> Do you see any holes in this approach?
No. In fact this is even simpler and straightforwa... - 02:50 PM Bug #4796 (WIP): locking regression in RAQ introduced with the FFC
- 02:50 PM Bug #4796: locking regression in RAQ introduced with the FFC
- Eric Faulhaber wrote:
> As I think more about this, we may need to use the cache result only for NO-LOCK requests,... - 02:26 PM Bug #4796: locking regression in RAQ introduced with the FFC
- Ovidiu Maxiniuc wrote:
> I copied the area which handles the locking, but I am trying to avoid code duplication u... - 01:34 PM Bug #4796: locking regression in RAQ introduced with the FFC
- h3. Initial issue:
When we have a FF cache hit, we do not honor the record lock request of the @FIND@. So, a requ... - 01:28 PM Bug #4796 (WIP): locking regression in RAQ introduced with the FFC
- 03:00 PM Bug #4797: review Persistence.load, as called by RAQ.executeImpl
- I think this method is not quite right in 4011b. It will load the record requested and get the lock type, but the @fo...
- 02:57 PM Bug #4797 (New): review Persistence.load, as called by RAQ.executeImpl
07/19/2020
- 07:05 AM Feature #4011: database/persistence layer performance improvements
- I committed rev 11575, which defers storing buffers whose scopes are opened in the @BufferManager.openBuffers@ list, ...
07/17/2020
- 06:37 PM Support #4702: write temp-table performance test cases
- I've added section how to run performance testcases from the new testcases project: https://proj.goldencode.com/proje...
- 10:28 AM Support #4702: write temp-table performance test cases
- The H2 performance testcases have been committed into the new testcases project as rev 668. They have been removed fr...
- 04:42 PM Feature #4022: upgrade to a newer PostgreSQL release
- At this point there is now a PostgreSQL 13.0. I don't think we should waste time on the intermediate versions.
- 04:22 PM Feature #4022: upgrade to a newer PostgreSQL release
- Just a note that the last VM I created used PL/java 1.5.5 and PostgreSQL 10.
- 04:16 PM Feature #4022 (WIP): upgrade to a newer PostgreSQL release
07/16/2020
- 04:23 PM Feature #4011: database/persistence layer performance improvements
- I have committed 4011b/11564, which skips the index lookup in @RAQ.initialize@ if the table being queried has no lega...
- 04:08 PM Feature #4011: database/persistence layer performance improvements
- It seems to be that the message is misleading. If the record fails a unique index validation, that line is in fact un...
- 03:49 PM Feature #4011: database/persistence layer performance improvements
- Ovidiu, based on this comment in @Persister.update@:...
07/15/2020
- 07:49 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Done. Committed as revision 4011b / 11561.
- 07:43 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Looks good. Please merge if you're still there :-)
- 07:30 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Eric Faulhaber wrote:
> I'm concerned synchronizing on the cache instance might be too coarse for an active system, ... - 06:32 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Ovidiu Maxiniuc wrote:
> Eric,
> I committed r11563. It contains the last two issues: 3-level cache and synchroniza... - 05:26 PM Feature #4033 (WIP): avoid query for FIND unique when the current record in the buffer would matc...
- Eric,
I committed r11563. It contains the last two issues: 3-level cache and synchronization. I must admit I did not... - 04:04 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- It is a bug in @SavepointManager.registerBlockHooks@. We should be differentiating between full and sub-transaction, ...
- 03:55 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Eric Faulhaber wrote:
> I think if you already have the cache invalidation logic in @SavepointManager@, we should be... - 03:34 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- @SavepointManager@ registers for the same master transaction rollback hook that is leading to this call, so it should...
- 03:21 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Eric Faulhaber wrote:
> From where is @Session.rollback@ called in this case?... - 03:17 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- From where is @Session.rollback@ called in this case?
- 03:10 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Eric Faulhaber wrote:
> For the invalidation on UNDO, please see @SavepointManager$Block.rollback(Session)@.
In t... - 10:51 AM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Greg Shah wrote:
> Now is the time to get this right. The 4GL deals with things at an index level and we should str... - 10:31 AM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Eric Faulhaber wrote:
> > * I had a thought or two on dirty database and whether those operation. As long as it do n... - 06:23 AM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- > I think what we need to do is, just before the loop which rolls back the elements of the @changed@ set, collect the...
- 11:11 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- What is your plan regarding thread safety for the shared form of the cache?
- 11:10 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- For the invalidation on UNDO, please see @SavepointManager$Block.rollback(Session)@.
I think what we need to do is... - 11:02 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Eric Faulhaber wrote:
> Everything else looks good, though we are still missing synchronization and invalidation o... - 10:49 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Code review 4011c/11561:
In @RAQ.initialize@, it seems we no longer need to make the lookup of the index informati... - 10:16 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Ovidiu Maxiniuc wrote:
> Eric,
>
> I adjusted the code as you suggested. The @findNext@/@findPrevious@ disappeare... - 07:03 PM Feature #3814: more schema metadata
- Greg Shah wrote:
> If it is just for analysis for this task, it is fine. I just want to be clear that we should not... - 06:58 PM Feature #3814: more schema metadata
- If it is just for analysis for this task, it is fine. I just want to be clear that we should not expect to do an imp...
- 06:09 PM Feature #3814: more schema metadata
- Greg,
DMO annotations keeps the properties which are defined in the @.df@ file. They all are already added to the DM... - 05:51 PM Feature #3814: more schema metadata
- We don't want to import this data. Why spend time on this when we want the DMO annotations to hold everything needed...
- 05:32 PM Feature #3814: more schema metadata
- The problems has multiple reasons.
1. The table dump from the Data Administrator skips some fields for the reason I ... - 01:14 PM Feature #4055 (WIP): optimize temp-table output parameter copying
- The changes are in 4011b rev 11559 Please review.
- 06:05 AM Feature #4011: database/persistence layer performance improvements
- Eric Faulhaber wrote:
> Constantin Asofiei wrote:
> > Eric Faulhaber wrote:
> > > Why not create an array which ma...
07/14/2020
- 07:32 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Eric,
I adjusted the code as you suggested. The @findNext@/@findPrevious@ disappeared by themselves. By extracting... - 05:47 AM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Ovidiu Maxiniuc wrote:
> I have just committed r11557 of 4011c.
> Changes:
> * I introduced a numeric identifier f... - 05:39 PM Bug #4760 (WIP): new keywords added in H2 1.4.200
- I've added in 4011b rev 11556 all the keywords not accepted by H2, to @P2JH2Dialect@. NameConverter is not required ...
- 04:30 PM Bug #4760: new keywords added in H2 1.4.200
- Ovidiu Maxiniuc wrote:
> Constantin,
>
> I am not sure, but that these special non-reserved keywords which can be... - 03:49 PM Bug #4760: new keywords added in H2 1.4.200
- Constantin,
I am not sure, but that these special non-reserved keywords which can be used a field/table names migh... - 02:48 PM Bug #4760: new keywords added in H2 1.4.200
- In @org.h2.util.ParserUtil@, there are lots of constants defining various tokens. Not all can be used in a column na...
- 02:42 PM Bug #4760 (Closed): new keywords added in H2 1.4.200
- 05:32 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Eric Faulhaber wrote:
> > Why not create an array which maps the @PropertyMeta@ objects... - 05:24 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Constantin Asofiei wrote:
> > > Does the destination record need to have a copy of the ... - 04:36 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> > Does the destination record need to have a copy of the source DMO's current meta-state... - 04:35 PM Feature #4011: database/persistence layer performance improvements
- Eric Faulhaber wrote:
> Wait, I just looked at this more closely. Is there any functional reason we need to convert ... - 04:33 PM Feature #4011: database/persistence layer performance improvements
- Eric Faulhaber wrote:
> A question which remains in my mind w.r.t. the copy operations is about LOBs. Will this work... - 03:49 PM Feature #4011: database/persistence layer performance improvements
- A question which remains in my mind w.r.t. the copy operations is about LOBs. Will this work for LOBs in their curren...
- 03:36 PM Feature #4011: database/persistence layer performance improvements
- Wait, I just looked at this more closely. Is there any functional reason we need to convert to/from BDT instances? If...
- 03:22 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> As I mentioned above, I had to change @Record.getData()@ to expose the @data[]@ array ... - 03:19 PM Feature #4011: database/persistence layer performance improvements
- Eric Faulhaber wrote:
> Constantin Asofiei wrote:
>
> > For copying the after-table record to before-table, I can... - 03:01 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> For copying the after-table record to before-table, I can use something like this, as ... - 02:38 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Eric Faulhaber wrote:
> > Since this temp-table copy is a common operation, I would l... - 12:45 PM Feature #4011: database/persistence layer performance improvements
- Eric Faulhaber wrote:
> So, @copyDMO@ needs review anyway, as it may be broken, but that is outside the scope of you... - 02:23 PM Feature #4055: optimize temp-table output parameter copying
- Constantin Asofiei wrote:
> At this point, what is left is:
> # improve @RecordBuffer.copyDMO@ (see #4011-773)
I n... - 12:47 PM Feature #4055: optimize temp-table output parameter copying
- At this point, what is left is:
# improve @RecordBuffer.copyDMO@ (see #4011-773)
# refactor @TemporaryBuffer.copyAl... - 01:45 PM Support #4701: try to improve H2 transaction commit performance
- Adrian, have you found any other potential areas of improvement in H2, based on any of the testing/profiling you have...
- 01:43 PM Support #4701: try to improve H2 transaction commit performance
- Constantin Asofiei wrote:
> Is there a place in the H2 source-code where all keywords are defined?
I am not fa... - 09:42 AM Support #4701: try to improve H2 transaction commit performance
- Eric/Adrian/Stanislav: H2 v 1.4.200 introduced new keywords, for example @array@. This statement works with 1.4.197 ...
- 08:01 AM Support #4701: try to improve H2 transaction commit performance
- After Java profiling the #4701-17 testcase, I got the following results for 1.4.200 patched:
!profiling_mv_vs_page... - 06:50 AM Support #4701: try to improve H2 transaction commit performance
- Below there is a comparison between 1.4.197 patched using PageStore, 1.4.200 patched using PageStore and 1.4.200 usin...
07/13/2020
- 06:40 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- I have just committed r11557 of 4011c.
Changes:
* I introduced a numeric identifier for indexes. In fact, the were ... - 04:46 AM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- OK, let's use @RecordIdentifier@. We may need to intern the strings, but this has a performance cost of its own. In t...
- 04:24 AM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Eric Faulhaber wrote:
> Why is the @FastFindCache$Result@ class necessary? I am not sure what the @L1Key@ and @L2Key... - 03:27 AM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- I reviewed the implementation as of 4011c/11555. In addition to my previous answers in #4033-31, which among other th...
- 05:55 PM Feature #4055: optimize temp-table output parameter copying
- Eric Faulhaber wrote:
> Since we currently use an internal counter to assign the next primary key for temp-tables (o... - 05:53 PM Feature #4055: optimize temp-table output parameter copying
- Since we currently use an internal counter to assign the next primary key for temp-tables (or the reclaimed keys), ho...
- 05:49 PM Feature #4055: optimize temp-table output parameter copying
- Eric Faulhaber wrote:
> The INSERT INTO ... SELECT FROM ... syntax documented for H2 suggests that the SELECT portio... - 05:43 PM Feature #4055: optimize temp-table output parameter copying
- Constantin Asofiei wrote:
> I need them to be incremental so I can make some assumptions;...
OK, that's what I wa... - 05:26 PM Feature #4055: optimize temp-table output parameter copying
- Eric Faulhaber wrote:
> I don't know of a way to force the SELECT to use a particular index with H2. That is up to t... - 05:11 PM Feature #4055: optimize temp-table output parameter copying
- Constantin Asofiei wrote:
> Eric Faulhaber wrote:
> > I don't follow. Isn't this what we want? Each @_multiplex@ va... - 05:03 PM Feature #4055: optimize temp-table output parameter copying
- Given an sql index name, how can I get its component fields, using the new RecordMeta/DmoMeta/etc support?
Or bett... - 04:29 PM Feature #4055: optimize temp-table output parameter copying
- Well, I remember now. I had the same epiphany when I implemented @write-xml@ and compare the xml output with informat...
- 04:22 PM Feature #4055: optimize temp-table output parameter copying
- Ovidiu Maxiniuc wrote:
> Constantin Asofiei wrote:
> > Ovidiu, please remind me - what's the default index for the ... - 03:28 PM Feature #4055: optimize temp-table output parameter copying
- Eric Faulhaber wrote:
> I don't follow. Isn't this what we want? Each @_multiplex@ value represents a distinct temp-... - 03:24 PM Feature #4055: optimize temp-table output parameter copying
- Constantin Asofiei wrote:
> H2 will use the @_multiplex@ index and after that sort the records by @recid@.
>
> ... - 03:16 PM Feature #4055: optimize temp-table output parameter copying
- Constantin Asofiei wrote:
> Ovidiu, please remind me - what's the default index for the before-table? I recall somet... - 02:59 PM Feature #4055: optimize temp-table output parameter copying
- Eric Faulhaber wrote:
> Constantin Asofiei wrote:
> > New question: why don't we have a @multiplex, recid@ default ... - 02:41 PM Feature #4055: optimize temp-table output parameter copying
- Constantin Asofiei wrote:
> New question: why don't we have a @multiplex, recid@ default index for temp-tables?
W... - 02:31 PM Feature #4055: optimize temp-table output parameter copying
- New question: why don't we have a @multiplex, recid@ default index for temp-tables?
- 02:25 PM Feature #4055: optimize temp-table output parameter copying
- There's an issue with using @nextVal@ in a SELECT. Looks like the sequence values are retrieved FIRST (I don't know ...
- 01:34 PM Feature #4055: optimize temp-table output parameter copying
- Ovidiu, please remind me - what's the default index for the before-table? I recall something like @row-state@ being p...
- 11:07 AM Feature #4055: optimize temp-table output parameter copying
- Constantin Asofiei wrote:
> Argh, I haven't realized before that the sequences are global - and if we define it as @... - 10:14 AM Feature #4055: optimize temp-table output parameter copying
- Argh, I haven't realized before that the sequences are global - and if we define it as @seq_tt1@, any user working on...
- 04:24 PM Feature #4011: database/persistence layer performance improvements
- Ovidiu Maxiniuc wrote:
> Unfortunately, we cannot use @dst.copy(src)@ as the order of fields is not the same, even i... - 04:22 PM Feature #4011: database/persistence layer performance improvements
- Unfortunately, we cannot use @dst.copy(src)@ as the order of fields is not the same, even if the set of the fields ar...
- 04:17 PM Feature #4011: database/persistence layer performance improvements
- Ovidiu Maxiniuc wrote:
> Constantin,
>
> Please verify whether
> [...]
> and
> [...]
>
> are compatible in... - 02:17 PM Feature #4011: database/persistence layer performance improvements
- Greg Shah wrote:
> I wonder if we are missing out on an opportunity caused by the 4GL behavior here. It is my under... - 02:01 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Eric, I've fixed @RecordBuffer.copyDMO@ (including extent fields), but I need some input... - 01:41 PM Feature #4011: database/persistence layer performance improvements
- Eric Faulhaber wrote:
> Eugenie Lyzenko wrote:
> > The @4011b@ rev @11555@ runtime does not with previously convert... - 01:16 PM Feature #4011: database/persistence layer performance improvements
- Eugenie Lyzenko wrote:
> The @4011b@ rev @11555@ runtime does not with previously converted application/DB.
>
> D... - 12:36 PM Feature #4011: database/persistence layer performance improvements
- The @4011b@ rev @11555@ runtime does not with previously converted application/DB.
Do I have to reconvert/re-impor... - 11:50 AM Feature #4011: database/persistence layer performance improvements
- Constantin,
Please verify whether... - 11:43 AM Feature #4011: database/persistence layer performance improvements
- I wonder if we are missing out on an opportunity caused by the 4GL behavior here. It is my understanding that the co...
- 11:07 AM Feature #4011: database/persistence layer performance improvements
- Eric, I've fixed @RecordBuffer.copyDMO@ (including extent fields), but I need some input with how you would like thin...
- 09:14 AM Feature #4011: database/persistence layer performance improvements
- Ovidiu Maxiniuc wrote:
> Actually, no.
> IIRC, that method will work with different DMO definitions: the method wor... - 08:26 AM Feature #4011: database/persistence layer performance improvements
- Actually, no.
IIRC, that method will work with different DMO definitions: the method worked passing two temp-tables ... - 07:39 AM Feature #4011: database/persistence layer performance improvements
- Ovidiu, one more thing please: @TemporaryBuffer.copyDMO@ no longer works in 4011b, as there are no declared fields in...
- 07:32 AM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Ovidiu, a call like @ScrollableResults.get(0, TempRecord.class)@ is not valid in FWD, ri... - 07:22 AM Feature #4011: database/persistence layer performance improvements
- Ovidiu, a call like @ScrollableResults.get(0, TempRecord.class)@ is not valid in FWD, right? We should use @Scrollabl...
- 02:29 PM Feature #3814: more schema metadata
- Igor Skornyakov wrote:
> I'm trying to create an H2 database containing all metatables from a large customer databas... - 02:02 PM Support #4702: write temp-table performance test cases
- In the chart it should be "197", not "192".
- 02:00 PM Support #4702: write temp-table performance test cases
- According to test results, MVStore (mv_store=true) is significantly slower than PageStore (mv_store=false). The red s...
- 04:08 AM Support #4702: write temp-table performance test cases
- Yes, I'd like to see a comparison of your tests with:
* 1.4.197 (patched) PageStore
* 1.4.200 (patched) PageStore... - 03:58 AM Support #4702: write temp-table performance test cases
- > BTW, did you do any testing with the MVStore engine? In my previous experience, FWD was slower with MVStore, but I ...
- 03:49 AM Support #4702: write temp-table performance test cases
- > Do they claim this?
They do: https://webcache.googleusercontent.com/search?q=cache:OZQ8T12NI00J:https://github.c... - 03:44 AM Support #4702: write temp-table performance test cases
- Stanislav Lomany wrote:
> PageStore engine is always single-threaded
Do they claim this? That doesn't seem righ... - 03:38 AM Support #4702: write temp-table performance test cases
- > The removal of @MULTI_THREADED@ (from H2, not 4011b) is a little concerning. Do you have any more information on wh...
- 02:24 AM Support #4702: write temp-table performance test cases
- Eric Faulhaber wrote:
> Please go ahead and commit these changes to 4011b, since we are moving to v1.4.200 now for... - 11:21 AM Support #4701: try to improve H2 transaction commit performance
- > Adrian, I should have confirmed this at the beginning, but was your performance comparison work done with the MVSto...
- 04:32 AM Support #4701: try to improve H2 transaction commit performance
- Constantin Asofiei wrote:
> Adrian Lungu wrote:
> > By this, I mean that the synchronization in @Session.cleanTempT... - 03:45 AM Support #4701: try to improve H2 transaction commit performance
- Adrian, I should have confirmed this at the beginning, but was your performance comparison work done with the MVStore...
- 03:20 AM Support #4701: try to improve H2 transaction commit performance
- Adrian Lungu wrote:
> By this, I mean that the synchronization in @Session.cleanTempTables@ is done way more rare (t... - 02:28 AM Support #4701: try to improve H2 transaction commit performance
- Eric Faulhaber wrote:
> Adrian, we will start using this version of H2 (i.e., 1.4.200, patched) as the default with ... - 02:26 AM Support #4701: try to improve H2 transaction commit performance
- We have upgraded to H2 v1.4.200 (patched), starting with 4011b/11555.
07/11/2020
- 09:09 AM Support #4701: try to improve H2 transaction commit performance
- I attached the @src/main/org/h2/engine/Session.java@ file.
> # A lot of users are accessing the database. @org.h2... - 09:51 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Ovidiu Maxiniuc wrote:
> The @Session@ works with its 'proprietary' @CacheKey@ key. I switched to it (making it pu... - 08:48 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Eric Faulhaber wrote:
> Is there a practical problem caused by the temp-table IDs not being re-usable, or is the pro...
07/10/2020
- 06:15 PM Support #4702: write temp-table performance test cases
- Stanislav Lomany wrote:
> For the case I'm attaching changes I made to 4011b in order to run H2 200 which are:
>
... - 05:18 PM Support #4702: write temp-table performance test cases
- For the case I'm attaching changes I made to 4011b in order to run H2 200 which are:
# @Constants.getFullVersion()@ ... - 05:13 PM Bug #4752: Possible broken sort clause with word indexes
- While working on other issues related to WORD indexes I realized something that seems like needing further investigat...
- 05:05 PM Bug #4752 (New): Possible broken sort clause with word indexes
- 03:55 PM Feature #3814: more schema metadata
- I'm trying to create an H2 database containing all metatables from a large customer database for a detailed analysis....
- 03:03 PM Support #4701: try to improve H2 transaction commit performance
- Adrian Lungu wrote:
> # A lot of local temp-tables are used concurrently.
This is something in use by customer appl... - 12:49 PM Support #4701: try to improve H2 transaction commit performance
- Adrian, we will start using this version of H2 (i.e., 1.4.200, patched) as the default with 4011b. Please update the ...
- 09:49 AM Support #4701: try to improve H2 transaction commit performance
- The @org.h2.Session.cleanTempTables@ direction was a good starting point. H2 was sequentially checking all local temp...
- 02:56 PM Feature #4011: database/persistence layer performance improvements
- Eric Faulhaber wrote:
> Are there really no other cases where the buffer scope can be smaller than the external proc... - 02:16 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Here I considered that @activeScopeDepth@ is the scope depth where the buffer was open... - 01:38 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- I left the topic of synchronization pretty open. Could you please tell me what your thoughts are there? Of course, th...
- 12:43 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Ovidiu Maxiniuc wrote:
> More details from 4011c/11554:
> * I added a table/DMO unique ID. This (the Level1key) is ...
Also available in: Atom