Re: [Firebird-devel] Latest OLTP results DB size resolved
2019. 02. 14. 21:07 keltezéssel, Karol Bieniaszewski írta: >> Can you execute same SS (2.5 vs 3.0) tests with 5 ISQL sessions? I do not know what purpose for only 5 ISQL but here you are. Thank you very much! Gabor Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Values for isc_dpb_session_time_zone
On 17/02/2019 08:33, Mark Rotteveel wrote: > It would be helpful if Firebird already had an explicit default value > (as then I can just document that, and I don't need to have logic to > treat a Jaybird specific value as 'don't set'). I don't think it should. Just don't add it to DPB. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Values for isc_dpb_session_time_zone
On 17/02/2019 08:08, Mark Rotteveel wrote: > Does isc_dpb_session_time_zone have an explicit default value? What I > mean is, can you set a value (maybe local?) that behaves as if the value > is not set (and thus uses the DefaultTimeZone config or system time zone)? > No. > In addition, is isc_dpb_session_time_zone case insensitive (ie will > Europe/Amsterdam behave the same as EUROPE/AMSTERDAM or europe/amsterdam)? > Yes. > What happens if a value is provided that does not exist? Will the > connection terminate with an error, will it provide a warning, or will > it silently use the DefaultTimeZone config or system time zone? > Error. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] RDB$GET_TRANSACTION_CN works different in Super and Classic
Open two connections C1 and C2. C2: select current_transaction from rdb$database; -- let's call the result T2 C2: commit; C1: select rdb$get_transaction_cn(T2) from rdb$database; In Super C1 returns the commit number. In Classic it returns NULL. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Interesting OLTP results on RAM Disk and question about
Hi. I resend and shortened this email because previous emails are gone on the list ☹ I set first only 2048 buffers as i supposed buffers does not matter on RAM DISK because read from file is really read from RAM. But to my surprise (maybe not so big surprise) the results are >3 times slower (vs cache 262144 buffers). Is this overhead because of using Windows file read API compared to direct read from cache or something else involved? This can be also because of cache processing. You know, if something is not in the cache, it must be read by Windows file API (here from memory). Then old data must be removed from cache and new one stored in the cache. Can someone profile this and catch where time is spend? On Win API or on cache storing/removing or somewhere else? PS> FB4 looks faster than FB3 ~7% - i test only one time FB4 then i must retest it. 48 isql sessions Server version: WI-T4.0.0.1435 Firebird 4.0 Beta 1 SUCCESSFUL TIMES DONE: 282094 vs 901743 Regards, Karol Bieniaszewski Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Interesting OLTP results on RAM Disk - question about results
I set first only 2048 buffers as i supposed buffers does not matter on RAM DISK because read from file is really read from RAM. But to my surprise (maybe not so big surprise) the results are as >3 times slower. Is this overhead becouse of using Windows file read api compared to direct read from cache or something else involved? PS> FB4 looks faster than FB3 ~7% - i test only one time FB4 then i must retest it. 48 isql sessions Server version: WI-T4.0.0.1435 Firebird 4.0 Beta 1 FB_ARCHITECTURE DB_NAME FORCED_WRITES SWEEP_INT PAGE_BUFFERS PAGE_SIZE SuperServer 4.0.0 P:\DB\OLTP4.FDB ON 2 2048 8192 ACTION AVG_TIMES_PER_MINUTE AVG_ELAPSED_MS SUCCESSFUL_TIMES_DONE JOB_BEG JOB_END *** OVERALL *** for 60 minutes: 4701.57 9891 282094 2019-02-16 18:35 2019-02-16 19:35 FB_ARCHITECTURE DB_NAME FORCED_WRITES SWEEP_INT PAGE_BUFFERS PAGE_SIZE SuperServer 4.0.0 P:\DB\OLTP4.FDB ON 2 262144 819 ACTION AVG_TIMES_PER_MINUTE AVG_ELAPSED_MS SUCCESSFUL_TIMES_DONE JOB_BEG JOB_END *** OVERALL *** for 60 minutes: 15029.05 5049 901743 2019-02-16 21:45 2019-02-16 22:45 For comparision 60 minutes tests for FB3 and FB2.5 FB_ARCHITECTURE DB_NAME FORCED_WRITES SWEEP_INT PAGE_BUFFERS PAGE_SIZE SuperServer 3.0.5 P:\DB\OLTP3.FDB ON 2 262144 8192 ACTION AVG_TIMES_PER_MINUTE AVG_ELAPSED_MS SUCCESSFUL_TIMES_DONE JOB_BEG JOB_END *** OVERALL *** for 60 minutes: 14005.30 5365 840318 2019-02-11 21:21 2019-02-11 22:21 FB_ARCHITECTURE DB_NAME FORCED_WRITES SWEEP_INT PAGE_BUFFERS PAGE_SIZE Classic 2.5.9 P:\DB\OLTP2.FDB ON 2 12288 8192 ACTION AVG_TIMES_PER_MINUTE AVG_ELAPSED_MS SUCCESSFUL_TIMES_DONE JOB_BEG JOB_END *** OVERALL *** for 60 minutes: 1164.40 48244 69864 2019-02-12 18:41 2019-02-12 19:41 FB_ARCHITECTURE DB_NAME FORCED_WRITES SWEEP_INT PAGE_BUFFERS PAGE_SIZE SuperClassic 2.5.9 P:\DB\OLTP2.FDB ON 2 12288 8192 ACTION AVG_TIMES_PER_MINUTE AVG_ELAPSED_MS SUCCESSFUL_TIMES_DONE JOB_BEG JOB_END *** OVERALL *** for 60 minutes: 6176.02 16168 370561 2019-02-12 21:35 2019-02-12 22:35 FB_ARCHITECTURE DB_NAME FORCED_WRITES SWEEP_INT PAGE_BUFFERS PAGE_SIZE SuperServer 2.5.9 P:\DB\OLTP2.FDB ON 2 262144 8192 ACTION AVG_TIMES_PER_MINUTE AVG_ELAPSED_MS SUCCESSFUL_TIMES_DONE JOB_BEG JOB_END *** OVERALL *** for 60 minutes: 1263.35 46980 75801 2019-02-13 00:07 2019-02-13 01:07 Regards, Karol Bieniaszewski Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] ODP: Interesting OLTP results on RAM Disk - question about results
This can ve also becaouse of cache processing. You know if something is not in cache it must bue read by win file api (here from memory) Then something must be removed from cache and stored int the cache. Can someone profile this and catch where time is spend on win api or on cache storing/removing or somewhere else? --- I set first only 2048 buffers as i supposed buffers does not matter on RAM DISK because read from file is really read from RAM. But to my surprise (maybe not so big surprise) the results are as >3 times slower. Is this overhead becouse of using Windows file read api compared to direct read from cache or something else involved? PS> FB4 looks faster than FB3 ~7% - i test only one time FB4 then i must retest it. 48 isql sessions Server version: WI-T4.0.0.1435 Firebird 4.0 Beta 1 FB_ARCHITECTURE DB_NAME FORCED_WRITES SWEEP_INT PAGE_BUFFERS PAGE_SIZE SuperServer 4.0.0 P:\DB\OLTP4.FDB ON 2 2048 8192 ACTION AVG_TIMES_PER_MINUTE AVG_ELAPSED_MS SUCCESSFUL_TIMES_DONE JOB_BEG JOB_END *** OVERALL *** for 60 minutes: 4701.57 9891 282094 2019-02-16 18:35 2019-02-16 19:35 FB_ARCHITECTURE DB_NAME FORCED_WRITES SWEEP_INT PAGE_BUFFERS PAGE_SIZE SuperServer 4.0.0 P:\DB\OLTP4.FDB ON 2 262144 819 ACTION AVG_TIMES_PER_MINUTE AVG_ELAPSED_MS SUCCESSFUL_TIMES_DONE JOB_BEG JOB_END *** OVERALL *** for 60 minutes: 15029.05 5049 901743 2019-02-16 21:45 2019-02-16 22:45 For comparision 60 minutes tests for FB3 and FB2.5 FB_ARCHITECTURE DB_NAME FORCED_WRITES SWEEP_INT PAGE_BUFFERS PAGE_SIZE SuperServer 3.0.5 P:\DB\OLTP3.FDB ON 2 262144 8192 ACTION AVG_TIMES_PER_MINUTE AVG_ELAPSED_MS SUCCESSFUL_TIMES_DONE JOB_BEG JOB_END *** OVERALL *** for 60 minutes: 14005.30 5365 840318 2019-02-11 21:21 2019-02-11 22:21 FB_ARCHITECTURE DB_NAME FORCED_WRITES SWEEP_INT PAGE_BUFFERS PAGE_SIZE Classic 2.5.9 P:\DB\OLTP2.FDB ON 2 12288 8192 ACTION AVG_TIMES_PER_MINUTE AVG_ELAPSED_MS SUCCESSFUL_TIMES_DONE JOB_BEG JOB_END *** OVERALL *** for 60 minutes: 1164.40 48244 69864 2019-02-12 18:41 2019-02-12 19:41 FB_ARCHITECTURE DB_NAME FORCED_WRITES SWEEP_INT PAGE_BUFFERS PAGE_SIZE SuperClassic 2.5.9 P:\DB\OLTP2.FDB ON 2 12288 8192 ACTION AVG_TIMES_PER_MINUTE AVG_ELAPSED_MS SUCCESSFUL_TIMES_DONE JOB_BEG JOB_END *** OVERALL *** for 60 minutes: 6176.02 16168 370561 2019-02-12 21:35 2019-02-12 22:35 FB_ARCHITECTURE DB_NAME FORCED_WRITES SWEEP_INT PAGE_BUFFERS PAGE_SIZE SuperServer 2.5.9 P:\DB\OLTP2.FDB ON 2 262144 8192 ACTION AVG_TIMES_PER_MINUTE AVG_ELAPSED_MS SUCCESSFUL_TIMES_DONE JOB_BEG JOB_END *** OVERALL *** for 60 minutes: 1263.35 46980 75801 2019-02-13 00:07 2019-02-13 01:07 Regards, Karol Bieniaszewski Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] test
test message, because i have send two emails 16.02.2019 23:12 and 16.02.2019 23:27 but i still do see them on the group regards, Karol Bieniaszewski Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-6002) system procedure named "TRANSITIONS" without "RDB$" prefix
system procedure named "TRANSITIONS" without "RDB$" prefix -- Key: CORE-6002 URL: http://tracker.firebirdsql.org/browse/CORE-6002 Project: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 4.0 Beta 1 Reporter: Segey Khalyutin Priority: Trivial select rdb$procedure_name, RDB$SYSTEM_FLAG from RDB$PROCEDURES where RDB$SYSTEM_FLAG = 1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-6001) slow select on RDB$PROCEDURE_PARAMETERS and RDB$FUNCTION_ARGUMENTS (index`s created on incorrect fields)
slow select on RDB$PROCEDURE_PARAMETERS and RDB$FUNCTION_ARGUMENTS (index`s created on incorrect fields) Key: CORE-6001 URL: http://tracker.firebirdsql.org/browse/CORE-6001 Project: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 4.0 Beta 2 Reporter: Segey Khalyutin Priority: Minor on table RDB$PROCEDURE_PARAMETERS index created on (RDB$RELATION_NAME,RDB$FIELD_NAME) instead of (RDB$PROCEDURE_NAME, RDB$PARAMETER_NAME) on table RDB$FUNCTION_ARGUMENTS index created on (RDB$RELATION_NAME,RDB$FIELD_NAME) instead of (RDB$FUNCTION_NAME , RDB$FIELD_NAME) in RDB$PROCEDURE_PARAMETERS RDB$RELATION_NAME and RDB$FIELD_NAME anywhere is null in RDB$RDB$FUNCTION_PARAMETERS RDB$RELATION_NAME anywhere is null -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Values for isc_dpb_session_time_zone
On 17-2-2019 12:08, Mark Rotteveel wrote: Does isc_dpb_session_time_zone have an explicit default value? What I mean is, can you set a value (maybe local?) that behaves as if the value is not set (and thus uses the DefaultTimeZone config or system time zone)? In addition, is isc_dpb_session_time_zone case insensitive (ie will Europe/Amsterdam behave the same as EUROPE/AMSTERDAM or europe/amsterdam)? What happens if a value is provided that does not exist? Will the connection terminate with an error, will it provide a warning, or will it silently use the DefaultTimeZone config or system time zone? As background to this question, Jaybird 4 is going to default to setting the session time zone to the Java Virtual Machine default time zone because of a number of JDBC expectations, and users who want the equivalent to the 'old' behaviour will need to 'unset' it. It would be helpful if Firebird already had an explicit default value (as then I can just document that, and I don't need to have logic to treat a Jaybird specific value as 'don't set'). The case (in)sensitivity and 'invalid' value behaviour is just something I want to be aware of (and maybe document). Mark -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Values for isc_dpb_session_time_zone
Does isc_dpb_session_time_zone have an explicit default value? What I mean is, can you set a value (maybe local?) that behaves as if the value is not set (and thus uses the DefaultTimeZone config or system time zone)? In addition, is isc_dpb_session_time_zone case insensitive (ie will Europe/Amsterdam behave the same as EUROPE/AMSTERDAM or europe/amsterdam)? What happens if a value is provided that does not exist? Will the connection terminate with an error, will it provide a warning, or will it silently use the DefaultTimeZone config or system time zone? Mark -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
