Top N queries and disbursion

Thanks a lot for your explanations.
We have started working with the snapshot and have found a problem with
the selectivity estimation of join clauses, probably you just know of
this.
When the join is between attnos < 0 (such as oids), the selectivity is
estimated as 0.5 (leading to very bad size estimates), since this code
in function compute_clause_selec (clausesel.c):

if (relid1 > 0 && relid2 > 0 && attno1 > 0 && attno2 > 0)
...
else
s1 = (Cost) (0.5);

So what is the aim of the last two and conditions?

Best regards

Roberto Cornacchia
Andrea Ghidini

We have finished our work on optimization of Top N queries (with clauses
STOP AFTER ... FOR EACH ... RANK BY ...) now it's time of validating it
with performance tests: since we are working on snapshots of the 6.6
release (now we are using snapshot dated 9/13/99) we are afraid of
instability problems to affect the results. Could you give us any
suggestion about this? We are quite close to the degree day, so we have
to optimize time usage...
BTW, first results seem to be interesting.

We would ask you for a last thing.
We need to estimate the number of distinct values of an attribute. We
thought 1/disbursion was the right solution, but the results were quite
wrong:
with 100 distinct values of an attribute uniformly distribuited in a
relation of 10000 tuples, disbursion was estimated as 0.002275, giving
us 440 distinct values. We have seen this disbursion estimates
result also in bad join selectivities estimate.
Could this be due to a bad disbursion estimate or is our solution
completely wrong?
Thanks a lot

Roberto Cornacchia
Andrea Ghidini