Re: pg_dump additional options for performance

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 26 Feb 2008 13:58:25 -0500
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> > IMO the place to start is COPY which is per my tests, slow. Multi
> > worker connection restore is great and I have proven that with some
> > work it can provide o.k. results but it is certainly not acceptable.
>
> It was already pointed out to you that we can hope for only
> incremental speedups in COPY per se. Don't be too quick to dismiss
> the discussion of large-grain parallelism, because I don't see
> anything else within reach that might give integer multiples rather
> than percentage points.

Oh please don't think I don't think this discussion is important, I
do. I would just hate to see us have 3 corners of a foundation. I also
don't buy the "incremental speedups". This may be arrogant of me but
that type of thought process is what allows for mediocre results.

HOT works because EDB refused to accept the inherit limitations of
PostgreSQL. COPY is no different in that aspect. Maybe it can't go
exponentially faster but the math says, "if done correctly, it can". We
just haven't figured out how.

Sincerely,

Joshua D. Drake

>
> regards, tom lane
>

- --
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL SPI Liaison | SPI Director | PostgreSQL political pundit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHxGOxATb/zqfZUUQRAs3oAJ4vpHEiRDUXPm1wqHWyIigVevoTbwCeJXa0
8bZAkOntTC9i/AHC3/L5w+8=
=gsUl
-----END PGP SIGNATURE-----