Re: BUG #4748: hash join and sort-merge join make different results
От | Roman Kononov |
---|---|
Тема | Re: BUG #4748: hash join and sort-merge join make different results |
Дата | |
Msg-id | 49D6EC92.1090609@ftml.net обсуждение исходный текст |
Ответ на | Re: BUG #4748: hash join and sort-merge join make different results (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #4748: hash join and sort-merge join make different results
|
Список | pgsql-bugs |
On 2009-04-03 23:32 Tom Lane said the following: > Roman Kononov <kononov@ftml.net> writes: >> On 2009-04-03 14:57 Tom Lane said the following: >>> I think we could fix this by having interval_hash() duplicate the >>> total-span calculation done by interval_cmp_internal, and then return >>> the hash of the resulting TimeOffset. This is going to break existing >>> hash indexes on intervals, but there seems little choice... > >> Consider hashing the result of justify_interval(). > > Uh, what's your point? We have to match interval_eq, not > justify_interval. For any two intervals a and b, saying that interval_cmp_interval(a,b)==0 is exactly the same as saying that (aj.month==bj.month && aj.day==bj.day && aj.time==bj.time), where aj=justify_interval(a) and bj=justify_interval(b). Therefore, instead of hashing interval_cmp_value() you can hash justify_interval(), where interval_cmp_value() is the transformation of intervals in interval_cmp_interval(). You said that hashing interval_cmp_value() breaks existing hash indexes. Hashing "justified" intervals avoids such breaking in some cases.
В списке pgsql-bugs по дате отправления: