Re: [HACKERS] initdb needed for newest sources
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] initdb needed for newest sources |
Дата | |
Msg-id | 29789.933566463@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] initdb needed for newest sources (Thomas Lockhart <lockhart@alumni.caltech.edu>) |
Ответы |
[HACKERS] A suggestion on finding those pesky .so files
Optimizer hints Selectivity estimates paper, and Mariposa |
Список | pgsql-hackers |
Thomas Lockhart <lockhart@alumni.caltech.edu> writes: >> The changes revise the contents of the pg_statistic system table >> in order to support more accurate selectivity estimation, as per >> discussions a few days ago. > Hey Tom, I'm not sure I was all that enthused about trying to optimize > the selectivity for *any* particular strategy. How about also allowing > the value(s) used for selectivity estimates to be manually set in the > table so folks can tune things to their satisfaction? Well, I'm more interested in putting my effort into making the system do the right thing without help. Manual overrides are OK as long as you remember to revisit the settings whenever anything changes ... otherwise your manual optimization can become manual pessimization ... But if you want to spend time on the manual approach, I have no objection. There's room for everyone to play. > Maybe they can already be set, in which case we could add a SET > OPTIMIZATION command (the name is negotiable) to make it easier? There's no manual inputs presently, except for some rather crude control variables (_enable_mergejoin_ and so on --- see backend/optimizer/path/costsize.c). There are a mixture of SET commands and backend command-line switches (ugh) to set these, and some don't have any tweak method short of source code changes or going in with a debugger. This area could use some cleanup and rethinking, for sure. regards, tom lane
В списке pgsql-hackers по дате отправления: