samekeys

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: hackers(at)postgreSQL(dot)org (PostgreSQL-development)
Subject: samekeys
Date: 1999-02-09 06:44:15
Message-ID: 199902090644.BAA12038@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

Browse pgsql-hackers by date

  From Date Subject
Next Message Vadim Mikheev 1999-02-09 06:57:46 Re: [HACKERS] TIME QUALIFICATION
Previous Message Clark Evans 1999-02-09 04:40:06 Using As with Inheritance?