Re: An idea for parallelizing COPY within one backend

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 />