Fw: AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards
От | Joe Conway |
---|---|
Тема | Fw: AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards |
Дата | |
Msg-id | 008601c0fd89$f047fb50$48d210ac@jecw2k1 обсуждение исходный текст |
Ответы |
Re: Fw: AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs.
Stand ards
|
Список | pgsql-hackers |
(Sorry if you receive this twice, but I sent it Saturday evening and it never made it to the list) Thanks for your thorough review and comments, Tom. Here's a new patch for review. Summary of changes/response to earlier comments: - add a routine for NullTest nodes -- done. - declare selectivity functions without fmgr notation -- done. - create selfuncs.h for declarations -- done, but I didn't move anything else out of builtins.h - use DatumGetBool() and adjust style -- done - create better default selectivities -- done: - DEFAULT_UNK_SEL = 0.005 - DEFAULT_NOT_UNK_SEL = 1 - DEFAULT_UNK_SEL - DEFAULT_BOOL_SEL = 0.5 - recurse clause_selectivity() for non-Var input -- done - simplify MCV logic -- done, used 2nd approach (always use the first most common val's frequency) Questions: - I added a debug define (BOOLTESTDEBUG) to selfuncs.h, and a corresponding ifdef/elog NOTICE to clause_selectivity(). This was to help me debug/verify the calculations. Should this be left in the code when I create a patch (it is in this one), and if so, is there a preferred "standard" approach to this type of debug code? - Using the debug code mentioned above, I noted that clause_selectivity() did not seem to get called at all for clauses like "where myfield = 0" or "where myfield > 0". I haven't looked too closely at it yet, but I was wondering if this is expected behavior? Thanks, -- Joe
В списке pgsql-hackers по дате отправления: