Re: unnesesary sorting after Merge Full Join
От | Tom Lane |
---|---|
Тема | Re: unnesesary sorting after Merge Full Join |
Дата | |
Msg-id | 5779.1204050934@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: unnesesary sorting after Merge Full Join (Gregory Stark <stark@enterprisedb.com>) |
Список | pgsql-general |
Gregory Stark <stark@enterprisedb.com> writes: > "Tom Lane" <tgl@sss.pgh.pa.us> writes: >> It might still be interesting sometime to have a more bespoke >> representation for a merged variable, but I guess we don't need >> it just for this. > It might have an advantage if you're doing a three-way outer join and neither > C(id1, C(id2,id3)) nor C(C(id2,id3), id1) match the requested order of > C(C(id1,id2), id3). Hmm ... couldn't we fix that if the COALESCE-builder were smart enough to flatten nested COALESCEs? AFAICS, C(C(x,y),z) == C(x,y,z) > It doesn't see too important to get that right since the outer joins can't be > reordered and the user could reasonably be expected to match the grouping of > his joins with his coalesce expression. Agreed, it's not real clear that nested full joins are something we need to be overly tense about right now. regards, tom lane
В списке pgsql-general по дате отправления: