Re: An idea for parallelizing COPY within one backend

Поиск
Список
Период
Сортировка
От Brian Hurt
Тема Re: An idea for parallelizing COPY within one backend
Дата
Msg-id 47C57C42.5000305@janestcapital.com
обсуждение исходный текст
Ответ на Re: An idea for parallelizing COPY within one backend  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: An idea for parallelizing COPY within one backend  ("Florian G. Pflug" <fgp@phlo.org>)
Список pgsql-hackers
Tom Lane wrote:<br /><blockquote cite="mid13568.1204087614@sss.pgh.pa.us" type="cite"><pre wrap="">"Florian G. Pflug"
<aclass="moz-txt-link-rfc2396E" href="mailto:fgp@phlo.org"><fgp@phlo.org></a> writes: </pre><blockquote
type="cite"><prewrap="">...
 
Neither the "dealer", nor the "workers" would need access to the either
the shared memory or the disk, thereby not messing with the "one backend
is one transaction is one session" dogma.
...   </pre></blockquote><pre wrap="">
Unfortunately, this idea has far too narrow a view of what a datatype
input function might do.  Just for starters, consider "enum" input,
which certainly requires catalog access.  We have also explicitly
acknowledged the idea that datatype I/O functions might try to store
typmod-related data in some special catalog somewhere.
        regards, tom lane
 </pre></blockquote> Would it be possible to determine when the copy is starting that this case holds, and not use the
parallelparsing idea in those cases?<br /><br /> I'm a big user of copy, generally into very simple tables- few
indexes,simple column types (numeric, varchar, and int almost exclusively), no fancy features.  A parallel copy input
inthe "simple" cases would be of great advantage to me, even if it doesn't parallelize "complicated" cases.<br /><br />
Brian<br/><br /> 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "A.M."
Дата:
Сообщение: Re: An idea for parallelizing COPY within one backend
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: An idea for parallelizing COPY within one backend