Den 2013-08-13 10:23 skrev Dimitry Sibiryakov såhär: > 13.08.2013 10:07, Dmitry Yemanov wrote: > >> Select Expression >> -> Aggregate >> -> Sort (unique) >> -> Sort (unique) >> -> Table "RDB$RELATIONS" Access By ID >> -> Index "RDB$INDEX_0" Scan >> Is it understandable that sorts are independent from each other but both >> dependent from the retrieval? I don't think so. > In this case for understandability I would suggest to reverse output > order: > > Select Expression > -> Index "RDB$INDEX_0" Scan > -> Table "RDB$RELATIONS" Access By ID > -> Sort (unique) > -> Aggregate > -> Sort (unique) > > This way it will be clear, IMHO, that index scan is first, feed data into > table access > and then its results are used for both sorts independently.
But we can't have different output order for different cases if the underlying order of operations is the same. That would be confusing. The core of the problem is that you're trying to use a tree-lika representation for something that's actually not a tree. I am currently unable to come up with a better option, but I feel some out of the box thinking would be beneficial here. Anyone? Kjell -- -------------------------------------- Kjell Rilbe DataDIA AB E-post: kj...@datadia.se Telefon: 08-761 06 55 Mobil: 0733-44 24 64 ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
