Re: [HACKERS] Parallel Append implementation
От | Thomas Munro |
---|---|
Тема | Re: [HACKERS] Parallel Append implementation |
Дата | |
Msg-id | CAEepm=3=X1XgNhY6r0dHrKiCk4Es_x+RDettE2A9z1GEaj5p9g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Parallel Append implementation (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] Parallel Append implementation
|
Список | pgsql-hackers |
On Wed, May 9, 2018 at 1:15 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Tue, May 8, 2018 at 12:10 AM, Thomas Munro > <thomas.munro@enterprisedb.com> wrote: >> It's not a scan, it's not a join and it's not an aggregation so I >> think it needs to be in a new <sect2> as the same level as those >> others. It's a different kind of thing. > > I'm a little skeptical about that idea because I'm not sure it's > really in the same category as far as importance is concerned, but I > don't have a better idea. Here's a patch. I'm worried this is too > much technical jargon, but I don't know how to explain it any more > simply. + scanning them more than once would preduce duplicate results. Plans that s/preduce/produce/ + <literal>Append</literal> or <literal>MergeAppend</literal> plan node. vs. + Append</literal> of regular <literal>Index Scan</literal> plans; each I think we should standardise on <literal>Foo Bar</literal>, <literal>FooBar</literal> or <emphasis>foo bar</emphasis> when discussing executor nodes on this page. -- Thomas Munro http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: