Обсуждение: samekeys
I have modified samekeys() again. It is now: for (key1 = keys1, key2 = keys2; key1 != NIL && key2 != NIL; key1 = lnext(key1), key2 = lnext(key2)) { for (key1a = lfirst(key1), key2a = lfirst(key2); key1a != NIL && key2a != NIL; key1a = lnext(key1a),key2a = lnext(key2a)) if (!equal(lfirst(key1a), lfirst(key2a))) return false; if (key1a != NIL) return false; } This basically says that key1, which is the old key, has to match key2 for the length of key1. If key2 has extra keys after that, that is fine. We will still consider the keys equal. The old code obviously was broken and badly thought out. One side benefit of this is that unorder joins that are the same cost as ordered joins are discarded, in the hopes the ordered joins can be used later on. OTIMIZER_DEBUG now shows:(9 8 ): size=1 width=8 path list: MergeJoin size=1 cost=0.000000 clauses=(x7.y = x8.y) sortouter=1 sortinner=1 SeqScan(8) size=0 cost=0.000000 SeqScan(9) size=0 cost=0.000000 MergeJoin size=1 cost=0.000000 clauses=(x7.y = x8.y) sortouter=1 sortinner=1 SeqScan(9) size=0 cost=0.000000 SeqScan(8) size=0 cost=0.000000 cheapest path: MergeJoin size=1 cost=0.000000 clauses=(x7.y = x8.y) sortouter=1 sortinner=1 SeqScan(8) size=0 cost=0.000000 SeqScan(9) size=0 cost=0.000000 Which is correct. The old code had many more plans for this simple join, perhaps 12, causing large optimizer growth with many tables. We now have an OPTDUP_DEBUG option to show key and PathOrder duplication testing. I am unsure if samekeys should just test the first key for equality, or the full length of key1 as I have done. Does the optimizer make use of the second key of a merged RelOptInfo for subsequent joins? My guess is that it does. For example, I keep plans that have key orders of 1,2,3 and 1,3,2. If only the first key is used in subsequent joins, I could just keep the cheapest of the two. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <maillist@candle.pha.pa.us> writes: > This basically says that key1, which is the old key, has to match key2 > for the length of key1. If key2 has extra keys after that, that is > fine. We will still consider the keys equal. The old code obviously > was broken and badly thought out. > ... > I am unsure if samekeys should just test the first key for equality, or > the full length of key1 as I have done. The comment in front of samekeys claimed: * It isn't necessary to check that each sublist exactly contain* the same elements because if the routine thatbuilt these* sublists together is correct, having one element in common* implies having all elements in common. Was that wrong? Or, perhaps, it was once right but no longer? It sounded like fragile coding to me, but I didn't have reason to know it was broken... regards, tom lane
> Bruce Momjian <maillist@candle.pha.pa.us> writes: > > This basically says that key1, which is the old key, has to match key2 > > for the length of key1. If key2 has extra keys after that, that is > > fine. We will still consider the keys equal. The old code obviously > > was broken and badly thought out. > > ... > > I am unsure if samekeys should just test the first key for equality, or > > the full length of key1 as I have done. > > The comment in front of samekeys claimed: > > * It isn't necessary to check that each sublist exactly contain > * the same elements because if the routine that built these > * sublists together is correct, having one element in common > * implies having all elements in common. > > Was that wrong? Or, perhaps, it was once right but no longer? > It sounded like fragile coding to me, but I didn't have reason > to know it was broken... I think it was wrong. It clearly was not passing the right parameters. As far as I know (1,2,3) and (3,2,1) are not the same. Their test would just take '1' and see if it is in (3,2,1). -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026