Re: IN vs =
От | Lukas |
---|---|
Тема | Re: IN vs = |
Дата | |
Msg-id | 19249.217.117.29.29.1233051034.squirrel@fmf.vgtu.lt обсуждение исходный текст |
Ответ на | Re: IN vs = (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Select START and MAXVALUE from Sequence
|
Список | pgsql-novice |
>> I would like to ask, what is the main difference between operators IN >> and >> '='. >> Then I use operator IN in JOIN it gives me much worse time (in my >> example >> ~3000ms) at the same time '=' gives 30ms! >> But the most interesting think is that at the begging (when DB was >> smaller) worked at the same speed as '=', why? > > Was it also on a different PG release back then? No, it was done on the same database (and same DBMS). >> LEFT JOIN b_mokejimu_sudengimai ON (mok_id IN (ms_mokejimas, >> ms_padengimas)) > >> Join Filter: (b_mokejimai.mok_id = ANY >> (ARRAY[b_mokejimu_sudengimai.ms_mokejimas, >> b_mokejimu_sudengimai.ms_padengimas])) > > The latest 8.2.x and 8.3.x releases contain a patch that avoids using > this construct when there are variables on the right-hand side; I think > that's your problem. Yes, we found the solution as shown, the question is why it is happening so? And also, what this patch does? changes the way how operator IN works? > (FWIW, most people would probably say that having to write a join like > this suggests you need to refactor your database structure...) Please comment it more - what is wrong with this join? (maybe you mean that it has to many joins in one query? Also, what do you mean by "refactor"? -- Lukas UAB nSoft http://www.nsoft.lt Lukas at nsoft.lt +370 655 10 655 -- This message has been scanned for viruses and dangerous content by OpenProtect(http://www.openprotect.com), and is believed to be clean.
В списке pgsql-novice по дате отправления: