Thread

1. Re: [HACKERS] optimizer pruning problem

   Roberto Cornacchia <rcorna@tin.it> — 1999-09-07T19:15:37Z

   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
   
   

2. Top N queries and disbursion

   Roberto Cornacchia <rcorna@tin.it> — 1999-10-07T17:47:21Z

   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