On 8.1.2013 03:47, Shigeru Hanada wrote: >>> * naming of DROP_RELATIONS_BSEARCH_LIMIT (or off-by-one bug?) >>> IIUC bsearch is used when # of relations to be dropped is *more* than >>> the value of DROP_RELATIONS_BSEARCH_LIMIT (10). IMO this behavior is >>> not what the macro name implies; I thought that bsearch is used for 10 >>> relations. Besides, the word "LIMIT" is used as *upper limit* in >>> other macros. How about MIN_DROP_REL[ATION]S_BSEARCH or >>> DROP_REL[ATION]S_LINEAR_SEARCH_LIMIT? >>> # using RELS instead of RELATIONS would be better to shorten the name >>> >> >> I've changed the name to DROP_RELS_BSEARCH_THRESHOLD. I believe this >> naming is consistent with options like "geqo_threshold" - when the >> number of relations reaches the specified value, the bsearch is used. >> >> I've also increased the value from 10 to 20, in accordance with the >> previous discussion. > > New name sounds good to me, but the #define says that the value is 15. > Should it be fixed to 20?
Ah, yes, please increase it to 20. I've increased it from 10 to 15 first, but I think 20 is nearer the optimal value and I forgot to change it in the code. > >>> * +1 for Alvaro's suggestion about avoiding palloc traffic by starting >>> with 8 elements or so. >>> >> >> Done. > > Not yet. Initial size of srels array is still 1 element. I've checked the patch and I see there 'maxrels = 8' - or do you mean something else? Tomas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
