Re: Possible documentation inaccuracy in optimizer README
От | David Rowley |
---|---|
Тема | Re: Possible documentation inaccuracy in optimizer README |
Дата | |
Msg-id | CAApHDvpbJrzQC-gZk0XpxMbk5CW=zj+R5KajuhP=Hw7xSdL5VQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Possible documentation inaccuracy in optimizer README (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Possible documentation inaccuracy in optimizer README
|
Список | pgsql-docs |
On Tue, 8 Apr 2025 at 16:28, Tom Lane <tgl@sss.pgh.pa.us> wrote: > We could possibly avoid the inaccuracy by making the examples use > some other operators that are not equijoins. But I wonder if that > would not be more confusing rather than less so. I don't think it'd hurt to mention that we're just ignoring the existence of ECs for this example. Something like: --- a/src/backend/optimizer/README +++ b/src/backend/optimizer/README @@ -143,7 +143,10 @@ For example: {1 2},{2 3},{3 4} {1 2 3},{2 3 4} {1 2 3 4} - (other possibilities will be excluded for lack of join clauses) + (other possibilities will be excluded for lack of join clauses + (technically, EquivalenceClasses do allow us to determine derived join + clauses for this case, but we ignore that for the simplicity of this + example)) SELECT * FROM tab1, tab2, tab3, tab4 If it'll stop a future question or someone from being confused, it seems worthwhile. David
В списке pgsql-docs по дате отправления: