On 04/29/14 13:49, Dimitry Sibiryakov wrote: > 29.04.2014 11:07, Alex wrote: >> On 04/29/2014 12:49 PM, Dimitry Sibiryakov wrote: >> >>> May be stop separate metadata cache at all and use ordinary data >>> cache for reading >>> system tables directly every time. >> And have prepare time increased many times... >> Not an option due to performance reasons. > System tables are likely to be in cache all the time. Besides, it is > enough to check > whether RDB$RECORD_VERSION still match value remembered in transaction > metadata cache object.
It's about reading table data from page cache when prepare gets slower many times. If system table is not in page cache it will be hundreds times slower. If you think that I give too pessimistic estimation here please compare searching data in btree index + analyzing data page with record version check + analysis for GC (all this done locking appropriate pages for read) on one side with finding record in an array by index on another side (that's how metadata cache works). You will see that provided estimation is correct. ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
