|
Hello Dimitry! I've got new ideas. VARIANT data type in PSQL - gain : a little memory and/or CPU overhead but much cleaner code. Also rdb$get/set_context value colud be variant. Optimization I. - temporal materialization. E.g. In this example the slow_proc called twice instead of one. Also the current solution have side effects (if slow_proc writes, it happens multiple times instead of one) WITH tmp AS ( SELECT p.result FROM slow_proc p ) SELECT * FROM tmp t1 CROSS JOIN tmp t2 Optimization II. - temporal indexing of materialization : e.g. when ORDER/GROUP BY has no index then currently the whole resultset is materialized, and the sorting moves the whole row each time. Instead of this it should create a temporal index on the order/group columns then fetching on the temporal index. In this way much less writes needed. This shold be applied after a treshold : common sense sais after index size/row size rate is smaller than 0.5. -- Molnár Attila szoftverfejlesztő Tel : 372-3333 E-mail: amol...@mve.hu LIBRA Szoftver zrt. 1113 Bp. Karolina út 65. Tel: 372-3333 Fax: 209-1477 Web: www.mve.hu E-mail: i...@mve.hu Olvasson ügyfeleinkkel elért közös sikereinkről: http://www.mve.hu/hu/referenciaink |
------------------------------------------------------------------------------ Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
