Activity
From 07/02/2020 to 07/31/2020
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 ...
07/09/2020
- 06:45 PM Support #4702: write temp-table performance test cases
- Testing results: each test is faster on H2 200 (fwd-h2-1.4.200-20200709) than on H2 197, in average 13% faster.
Test... - 04:44 PM Support #4702: write temp-table performance test cases
- I made some changes to FWD to make H2 200 run. Starting testing.
- 02:03 PM Support #4702: write temp-table performance test cases
- Stanislav, I will try to reproduce the exception and see if it related to @fwd-h2-1.4.200-20200709.jar@.
I remember... - 01:08 PM Support #4702: write temp-table performance test cases
- Results so far:
# Looks like "UPDATE using a query" test goes to infinite cycle in 4011b (H2 197) if the number of r... - 05:16 PM Feature #4011: database/persistence layer performance improvements
- Greg Shah wrote:
> Constantin: I have the following questions about @RecordBuffer.worldScope@.
>
> * Is the idea ... - 02:16 PM Feature #4011: database/persistence layer performance improvements
- Eric, something else to consider. In @Persister.insert@, we use @1 + sum(distinct field's extent)@ INSERT statements...
- 09:52 AM Feature #4011: database/persistence layer performance improvements
- I've generated several reports and exports at the @Guests@ tab. The only meaningful hotspot is:...
- 09:15 AM Feature #4011: database/persistence layer performance improvements
- The profiling of the Hotel GUI app (switching tabs) did not reveal any hot spots. The only thing which is worth to me...
- 01:46 AM Feature #4011: database/persistence layer performance improvements
- After patching directory.xml what I have for freshly imported DB and server start up:...
- 09:26 PM Feature #4011: database/persistence layer performance improvements
- Constantin: I have the following questions about @RecordBuffer.worldScope@.
* Is the idea that @worldScope == true... - 03:16 PM Feature #4055: optimize temp-table output parameter copying
- Constantin Asofiei wrote:
> A small note about the reclaimed keys - for the @INSERT INTO SELECT FROM@ approach to wo... - 03:00 PM Feature #4055: optimize temp-table output parameter copying
- A small note about the reclaimed keys - for the @INSERT INTO SELECT FROM@ approach to work, I need consecutive, incre...
- 01:12 PM Feature #4055: optimize temp-table output parameter copying
- Eric Faulhaber wrote:
> What is the exact problem in the @INSERT INTO ... SELECT FROM@ case? Maybe we can disable re... - 12:36 PM Feature #4055: optimize temp-table output parameter copying
- Constantin Asofiei wrote:
> Eric, a problem @INSERT INTO ... SELECT FROM@ is the primary key. How important is to u... - 12:20 PM Feature #4055: optimize temp-table output parameter copying
- For the PK generation, I'm using sequences (one per each temp-table) like this:
# before the @INSERT INTO ... SELECT... - 03:06 AM Feature #4055: optimize temp-table output parameter copying
- Eric, a problem @INSERT INTO ... SELECT FROM@ is the primary key. How important is to use the 'reclaimed keys' featu...
- 02:44 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- More details from 4011c/11554:
* I added a table/DMO unique ID. This (the Level1key) is the only place used, yet. Th...
07/08/2020
- 04:29 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Please note I have made some updates to #4033-22 to clarify handling of the "no record found" case.
- 04:05 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Ovidiu wrote (in email):
> I have created the general stubbing for the advanced cache but for the moment I do not ... - 04:00 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- FOR FIRST/LAST already is implemented by @RandomAccessQuery@, so we should get that for free.
FIND CURRENT should ... - 08:07 AM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Can we expand this usage beyond @FIND@?
It seems to me that the 4GL uses the same index-based technique for these ... - 07:28 AM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- I've tested this and modified your test case somewhat to stress the caching in different ways, and this definitely se...
- 03:20 PM Feature #4055: optimize temp-table output parameter copying
- Eric Faulhaber wrote:
> Constantin, I linked this with issue #3958 because it seems we should apply some of the same... - 02:28 PM Feature #4055: optimize temp-table output parameter copying
- Constantin, I linked this with issue #3958 because it seems we should apply some of the same ideas to both problems, ...
- 03:09 PM Feature #4011: database/persistence layer performance improvements
- Eric Faulhaber wrote:
> Agreed. Are you working on this, or do you want someone else to pick it up?
The fix was sim... - 02:52 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Eric Faulhaber wrote:
> > Does this patch work?
> >
> > [...]
> Well, my patch just... - 12:01 PM Feature #4011: database/persistence layer performance improvements
- Eric Faulhaber wrote:
> Does this patch work?
>
> [...]
Well, my patch just returned the correct 'nextStart' by ... - 08:26 AM Feature #4011: database/persistence layer performance improvements
- There is a bug related to validation/flushing. I have a record like this:...
- 02:39 PM Bug #4057: h2 performance degradation
- Stas, when do you think you will have findings, based on the #4702 test cases? Based on the comparison of versions in...
- 08:57 AM Feature #3814: more schema metadata
- Can we ask our customers (or at least some of them) to provide an export (.d files) of the meta-tables from their 4GL...
07/07/2020
- 07:34 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Eric Faulhaber wrote:
> Ovidiu, please prototype a basic query results cache for use with FIND {FIRST|LAST|unique} q... - 06:07 PM Feature #4011: database/persistence layer performance improvements
- Does this patch work?...
- 05:49 PM Feature #4011: database/persistence layer performance improvements
- Eric Faulhaber wrote:
> What is the layout of the result set you are working with?
There are 3 SELECT being execute... - 05:43 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Eric, my problem is that @props@ for the @MetaField@ DMO has its structure like this:
>... - 05:35 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> A side note: for a @FindQuery.canFindImpl@ call, do we really need to load the full reco... - 05:32 PM Feature #4011: database/persistence layer performance improvements
- A side note: for a @FindQuery.canFindImpl@ call, do we really need to load the full record in the database? Because t...
- 05:25 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> And if I switch it to @i = i + seriesSize@, then the @i@ will be wrong, but the return v... - 05:21 PM Feature #4011: database/persistence layer performance improvements
- Eric, my problem is that @props@ for the @MetaField@ DMO has its structure like this:
# 52 scalar props
# 48 entrie... - 05:14 PM Feature #4011: database/persistence layer performance improvements
- Eric Faulhaber wrote:
> Generally speaking, the data should always be laid out as described in the @Loader@ class ... - 05:11 PM Feature #4011: database/persistence layer performance improvements
- Before you make any changes at this low level, please explain the error you are seeing, which you are trying to solve.
- 05:09 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Eric/Ovidiu, someone please document and explain how @Loader.readExtentData@ should work... - 05:03 PM Feature #4011: database/persistence layer performance improvements
- Looking at the code, the protection against 'bad data' is not OK. The code should attempt to read exactly 'extent' r...
- 04:02 PM Feature #4011: database/persistence layer performance improvements
- Eric/Ovidiu, someone please document and explain how @Loader.readExtentData@ should work. My change which increments...
- 03:37 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> 4011b contains the fix for #4011-730 and other misc - please review.
The changes seem... - 02:56 PM Feature #4011: database/persistence layer performance improvements
- 4011b contains the fix for #4011-730 and other misc - please review.
- 10:44 AM Feature #4011: database/persistence layer performance improvements
- There is an issue with the @ProxyAssembler.assembleClass@ code. Here, we want to override all passed methods, and als...
- 03:31 PM Bug #4703 (Hold): investigate whether performance of TempTableDataSourceProvider can be improved
- 11:19 AM Support #4701: try to improve H2 transaction commit performance
- I created a test with 1000 temp-tables and the suggested loop. The transaction is in fact committed after each iterat...
- 03:26 AM Feature #3814: more schema metadata
- Igor Skornyakov wrote:
> Fixed the issue with the @null@ @ConnectionListener@ found in automated regression testing ...
07/06/2020
- 05:17 PM Feature #3814: more schema metadata
- Fixed the issue with the @null@ @ConnectionListener@ found in automated regression testing by Roger
Committed to 382... - 02:42 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- I want to finish the refactoring of the index support from strings to bit sets before we invest time in any conversio...
- 07:12 AM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- I understand. I just want us to keep in mind that it is easily possible to add a parameter to the query init that is...
- 06:20 AM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Greg Shah wrote:
> > Storing the index will require we look up the index for all such queries in RAQ.initialize, not... - 06:06 AM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- > Storing the index will require we look up the index for all such queries in RAQ.initialize, not just when we have a...
- 05:16 AM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Ovidiu, please prototype a basic query results cache for use with FIND {FIRST|LAST|unique} queries. The keys are a un...
- 02:11 PM Feature #4011: database/persistence layer performance improvements
- Greg Shah wrote:
> As part of this work, I've written changes to @ScopedDictionary@ to eliminate the use of the @Lis... - 12:55 PM Feature #4011: database/persistence layer performance improvements
- I'm still analyzing the @RecordBuffer.pinnedLockTypes@ usage.
As part of this work, I've written changes to @Scope... - 04:32 AM Feature #4011: database/persistence layer performance improvements
- Greg Shah wrote:
> *2.* Make @undone@ an instance member of @RecordBuffer@ instead of using the @extra@ object of ... - 12:43 PM Support #4701: try to improve H2 transaction commit performance
- Constantin Asofiei wrote:
> Adrian, in my profiling, I saw a significant time being spent in @orh.h2.Session.cleanTe... - 12:03 PM Support #4701: try to improve H2 transaction commit performance
- Adrian, in my profiling, I saw a significant time being spent in @orh.h2.Session.cleanTempTables@. Please create a t...
- 11:49 AM Support #4701: try to improve H2 transaction commit performance
- I investigated the H2 sources and eventually tried out some optimizations, but without any considerable performance b...
- 12:27 PM Bug #4742: heap usage increase on server startup
- 3821c rev 11387 contains the changes for this. @hbm_dmo_index.xml@ no longer exists in 4011b, and I'll postpone the ...
- 06:44 AM Bug #4703: investigate whether performance of TempTableDataSourceProvider can be improved
- Eric Faulhaber wrote:
> I don't think it is really worth it to contrive something in hand-written Java to recreate a... - 06:16 AM Bug #4703: investigate whether performance of TempTableDataSourceProvider can be improved
- I don't think it is really worth it to contrive something in hand-written Java to recreate a problem that we haven't ...
- 06:03 AM Bug #4703: investigate whether performance of TempTableDataSourceProvider can be improved
- Eric Faulhaber wrote:
> This is good news, but it suggests that the test did not recreate the condition I thought it... - 05:51 AM Bug #4703: investigate whether performance of TempTableDataSourceProvider can be improved
- This is good news, but it suggests that the test did not recreate the condition I thought it would, either because I ...
07/05/2020
- 07:34 PM Bug #4742: heap usage increase on server startup
- Eric, after clearing the H2 meta from the heap, a real leak appeared, related to my TRPL changes for incremental conv...
- 06:04 PM Bug #4742: heap usage increase on server startup
- Constantin Asofiei wrote:
> Eric, what's the proper way to ensure the Hibernate session is really flushed of cache... - 05:58 PM Bug #4742: heap usage increase on server startup
- Igor Skornyakov wrote:
> The issue described at #4742-12 is a result of the fact that the login/password for the met... - 03:52 PM Bug #4742: heap usage increase on server startup
- Igor, thanks for the help. The server heap was reduced with ~300MB, which is the size of the _meta database on disk,...
- 02:03 PM Bug #4742: heap usage increase on server startup
- The issue described at #4742-12 is a result of the fact that the login/password for the metadatabase is generated at ...
- 07:18 AM Bug #4742: heap usage increase on server startup
- Constantin Asofiei wrote:
> Igor, what URL needs to change so that the H2 meta database is on disk, instead of memor... - 06:03 AM Bug #4742: heap usage increase on server startup
- Igor, what URL needs to change so that the H2 meta database is on disk, instead of memory?
Please create a patch f... - 06:02 AM Bug #4742: heap usage increase on server startup
- From Eric:
> If all this data is correct and needed (i.e., there is not a bug/leak), we should take the metadata dat... - 05:46 AM Bug #4742: heap usage increase on server startup
- Constantin Asofiei wrote:
> Constantin Asofiei wrote:
> > ... and post here a list of all new fields added plus the... - 04:59 AM Bug #4742: heap usage increase on server startup
- Constantin Asofiei wrote:
> ... and post here a list of all new fields added plus their extent, in each table.
Look... - 04:55 AM Bug #4742: heap usage increase on server startup
- Igor, please do this: compare the standard.df we switched to in #3814 with the attached one (which is an old version,...
- 04:42 AM Bug #4742: heap usage increase on server startup
- Constantin Asofiei wrote:
> Igor, I have these stats:
> [...]
>
> Do you know if before you made your changes, t... - 04:30 AM Bug #4742: heap usage increase on server startup
- Igor, I have these stats:...
- 03:48 AM Bug #4742: heap usage increase on server startup
- In fact, albeit meta.xml is still parsed on startup, very few records are actually created from it (see the log). It ...
- 07:29 PM Feature #4011: database/persistence layer performance improvements
- Greg Shah wrote:
> *1.* Eliminate the call to @TriggerTracker.resetState()@ from @RecordBuffer.enterBlock()@.
> [... - 04:59 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Greg Shah wrote:
> > Is the primary problem this loop in @beginTx()@ and similar in @en...
07/04/2020
- 06:58 PM Bug #4742: heap usage increase on server startup
- Constantin Asofiei wrote:
> So this allows multiple records for the same file (and if my interpretation of the code ... - 06:28 PM Bug #4742: heap usage increase on server startup
- In a large customer application, it was noticed a heap usage increase on a freshly started FWD server. The assumptio...
- 06:07 PM Bug #4742 (New): heap usage increase on server startup
- 05:59 PM Support #4702: write temp-table performance test cases
- There is an issue running the update tests with 4011b/11544. Looks like we are getting into an infinite loop based on...
07/03/2020
- 06:36 PM Feature #4011: database/persistence layer performance improvements
- I don't understand how @Loader.readExtentData@ worked before. Shouldn't it increase the @i@ var by the @seriesSize@...
- 02:49 PM Feature #4011: database/persistence layer performance improvements
- Greg Shah wrote:
> Is the primary problem this loop in @beginTx()@ and similar in @endTx()@:
Exactly. The global sc... - 02:47 PM Feature #4011: database/persistence layer performance improvements
- Is the primary problem this loop in @beginTx()@ and similar in @endTx()@:...
- 01:26 PM Feature #4011: database/persistence layer performance improvements
- Eric Faulhaber wrote:
> In email, Constantin wrote:
>
> > @BufferManager.beginTx@ and @endTx@ both stand out in t... - 01:05 PM Feature #4011: database/persistence layer performance improvements
- In email, Constantin wrote:
> @BufferManager.beginTx@ and @endTx@ both stand out in the visualvm sampler. This is... - 04:34 AM Feature #4011: database/persistence layer performance improvements
- Ovidiu Maxiniuc wrote:
> I see, then we have a problem. The same API is used for INSERT/UPDATE statements. When a DT... - 04:34 PM Support #4701: try to improve H2 transaction commit performance
- I attached the patch based on @h2_synchronization_transactional_fix_20200703a.patch@, but compatible with the 1.4.200...
- 02:56 PM Support #4701: try to improve H2 transaction commit performance
- Adrian, please post the clean patches for the 1.4.200 source code base. Unless Stanislav's findings are vastly differ...
- 02:44 PM Support #4701: try to improve H2 transaction commit performance
- Stanislav,
I attached the h2 versions I used in testing. I can't attach the already built ones as they are too bi... - 09:34 AM Support #4701: try to improve H2 transaction commit performance
- Adrian, could you share 197 patched and 200 patched?
- 07:33 AM Support #4701 (WIP): try to improve H2 transaction commit performance
- 07:33 AM Support #4701: try to improve H2 transaction commit performance
- I have computed the testing results for 1.4.200 and 1.4.200 patched. The spreadsheet is attached and a representative...
- 04:16 PM Support #4702: write temp-table performance test cases
- FYI, I added some missing EOL markers to @perf-run-all-silent.p@ and committed the fix.
- 02:00 PM Bug #4703: investigate whether performance of TempTableDataSourceProvider can be improved
- I've tested calling one of Stanislav's tests (with minor changes to suppress output) as an external program in loop:
...
07/02/2020
- 07:36 PM Support #4702 (Review): write temp-table performance test cases
- I've committed all of the tests, including FOR EACH, FIND and BUFFER-COPY tests.
- 05:59 PM Support #4702: write temp-table performance test cases
- Eric Faulhaber wrote:
> Eric Faulhaber wrote:
>
> > I would like at least one test which "thrashes" JDBC connecti... - 06:28 AM Support #4702: write temp-table performance test cases
- Eric Faulhaber wrote:
> I would like at least one test which "thrashes" JDBC connections. That is, the test should... - 06:12 AM Support #4702: write temp-table performance test cases
- Stanislav Lomany wrote:
> Igor, I'm not managing connection. I suppose that is a part of your task.
> BTW, I just c... - 05:53 AM Support #4702: write temp-table performance test cases
- > Which of your tests is supposed to open/close multiple JDBC Connections?
Igor, I'm not managing connection. I su... - 04:21 AM Support #4702: write temp-table performance test cases
- Stanislav.
Which of your tests is supposed to open/close multiple JDBC Connections?
Thank you. - 04:58 PM Support #4701: try to improve H2 transaction commit performance
- Just found this in the H2 v1.4.200 change log, as something that was fixed:
* Issue # 1820: Performance problem on... - 04:05 PM Support #4701: try to improve H2 transaction commit performance
- I shared the findings in #4057. I will go ahead with testing the 1.4.200 version. Need just some syntax changes to th...
- 03:29 PM Support #4701: try to improve H2 transaction commit performance
- Adrian, this performance data presents an interesting counterpoint to the information posted previously to #4057. Ple...
- 11:26 AM Support #4701: try to improve H2 transaction commit performance
- I have done some testing using the Apache JMeter in order to see some differences between H2 versions: 1.4.196, 1.4.1...
- 04:14 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Ovidiu Maxiniuc wrote:
> > * @TypeManager.setFwdDatetimetzParameter()@ you decided not ... - 04:05 PM Feature #4011: database/persistence layer performance improvements
- Ovidiu Maxiniuc wrote:
> Review for 4011b rev 11537:
> * in which cases in @FqlToSqlConverter.getSqlColumnAlias@, t... - 04:00 PM Feature #4011: database/persistence layer performance improvements
- Review for 4011b rev 11537:
* in which cases in @FqlToSqlConverter.getSqlColumnAlias@, the @sqlName@ is null col "co... - 03:36 PM Feature #4011: database/persistence layer performance improvements
- More blob, clob and datetimetz fixes are in 4011b rev 11537.
- 03:34 PM Feature #4011: database/persistence layer performance improvements
- Ovidiu Maxiniuc wrote:
> They have an id reserved in @ReservedProperty@, indeed.
In the DMO interface, the annotat... - 03:33 PM Feature #4011: database/persistence layer performance improvements
- They have an id reserved in @ReservedProperty@, indeed.
However, if I remember correctly, they are true fields in d... - 03:17 PM Feature #4011: database/persistence layer performance improvements
- Ovidiu, is it normal for a before-table to explicitly generate the @_error-flag@, @_row-state@ and other related prop...
- 02:49 PM Feature #4011: database/persistence layer performance improvements
- I'm getting an NPE when checking in a guest in Hotel GUI:...
- 01:40 PM Feature #4011: database/persistence layer performance improvements
- Ovidiu Maxiniuc wrote:
> 4011b rev 11535 seems fine to me. It's really strange that PSQL dialect has so specials nee... - 01:23 PM Feature #4011: database/persistence layer performance improvements
- 4011b rev 11535 seems fine to me. It's really strange that PSQL dialect has so specials needs.
4011b rev 11536: one ... - 01:04 PM Feature #4011: database/persistence layer performance improvements
- 4011 rev 11536 has these:
* Ignore DMO properties like _error-flag, _row-state, etc, where only table-defined legacy... - 12:47 PM Feature #4011: database/persistence layer performance improvements
- 4011b rev 11535 completed implementation for blob, clob, comhandle, handle, object and raw field types. Please review.
- 12:47 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> This code in @TemporaryBuffer$Context.nextPrimaryKey@:
> [...]
OK, yes, I see now.... - 12:27 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> So, instead of @lte@, we should emit @tt1.f1 < ?@, and use @PreparedStatement.setTimesta... - 12:23 PM Feature #4011: database/persistence layer performance improvements
- Ovidiu Maxiniuc wrote:
> All our supported dialects have a field type which includes the time zone. However, they de... - 12:17 PM Feature #4011: database/persistence layer performance improvements
- Eric Faulhaber wrote:
> Constantin Asofiei wrote:
> > Constantin Asofiei wrote:
> > > Ovidiu/Eric: when does a del... - 12:07 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Constantin Asofiei wrote:
> > Ovidiu/Eric: when does a deleted record get evicted from ... - 11:57 AM Feature #4011: database/persistence layer performance improvements
- Committed @DirtyShareSupport@ class missing from last commit, as 4011b rev 11534.
- 11:35 AM Feature #4011: database/persistence layer performance improvements
- All our supported dialects have a field type which includes the time zone. However, they decided to support them diff...
- 10:47 AM Feature #4011: database/persistence layer performance improvements
- Ovidiu, in SQL, do we still need the '_offset' column when comparing a datetime-tz field with another (string represe...
- 09:02 AM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Ovidiu/Eric: when does a deleted record get evicted from the @orm.Session.cache@? I can'... - 08:42 AM Feature #4011: database/persistence layer performance improvements
- Ovidiu/Eric: when does a deleted record get evicted from the @orm.Session.cache@? I can't find any place for this... ...
- 06:36 AM Feature #4011: database/persistence layer performance improvements
- I have committed 4011a_rebase rev 11533, which fixes the CAN-FIND in the test case from #4011-577 and enables dirty s...
- 04:01 PM Bug #4057: h2 performance degradation
- I've done a testing effort in comparing 1.4.196, 1.4.197, 1.4.197 patched, 1.4.198 and 1.4.199. I shared the results ...
- 01:39 PM Bug #4703: investigate whether performance of TempTableDataSourceProvider can be improved
- FYI, 4011b is the branch for this work. 4011a and 4011a_rebase are now frozen.
Also available in: Atom