Re: An idea for parallelizing COPY within one backend
От
Florian G. Pflug
Тема
Re: An idea for parallelizing COPY within one backend
Дата
Msg-id
47C5881E.2040205@phlo.org
Ответ на
Список
Дерево обсуждения
An idea for parallelizing COPY within one backend "Florian G. Pflug" <fgp@phlo.org>
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>
Re: An idea for parallelizing COPY within one backend Brian Hurt <bhurt@janestcapital.com>
Re: An idea for parallelizing COPY within one backend "Florian G. Pflug" <fgp@phlo.org>
Re: An idea for parallelizing COPY within one backend Andrew Dunstan <andrew@dunslane.net>
Re: An idea for parallelizing COPY within one backend Brian Hurt <bhurt@janestcapital.com>
Re: An idea for parallelizing COPY within one backend "Florian G. Pflug" <fgp@phlo.org>
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>
Re: An idea for parallelizing COPY within one backend "Tom Dunstan" <pgsql@tomd.cc>
Re: An idea for parallelizing COPY within one backend Dimitri Fontaine <dfontaine@hi-media.com>
Re: An idea for parallelizing COPY within one backend Simon Riggs <simon@2ndquadrant.com>
Re: An idea for parallelizing COPY within one backend "Florian G. Pflug" <fgp@phlo.org>
Re: An idea for parallelizing COPY within one backend "A.M." <agentm@themactionfaction.com>
Re: An idea for parallelizing COPY within one backend Alvaro Herrera <alvherre@commandprompt.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 "Heikki Linnakangas" <heikki@enterprisedb.com>
Brian Hurt wrote: > Tom Lane wrote: >> "Florian G. Pflug" writes: >>> ... >>> 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. >>> ... >> 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. > Would it be possible to determine when the copy is starting that this > case holds, and not use the parallel parsing idea in those cases? In theory, yes. In pratice, I don't want to be the one who has to answer to an angry user who just suffered a major drop in COPY performance after adding an ENUM column to his table. I was thinking more along the line of letting a datatype specify a function "void* ioprepare(typmod)" which returns some opaque object specifying all that the input and output function needs to know. We could than establish the rule that input/output functions may not access the catalog, and instead pass them a pointer to that opaque object. All pretty pie-in-the-sky at the moment, though... regards, Florian Pflug
В списке pgsql-hackers по дате отправления
От: Heikki Linnakangas
Дата:
От: Paul van den Bogaard
Дата: