Re: pg_dump additional options for performance - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_dump additional options for performance
Date
Msg-id 7088.1204056227@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_dump additional options for performance  ("Joshua D. Drake" <jd@commandprompt.com>)
Responses Re: pg_dump additional options for performance  (Dimitri Fontaine <dfontaine@hi-media.com>)
List pgsql-hackers
"Joshua D. Drake" <jd@commandprompt.com> writes:
> 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".

You can always make it faster if it doesn't have to give the right
answer ;-).  Or in more practical terms in this case, we have to balance
speed against potentially-large costs in maintainability, datatype
extensibility, and suchlike issues if we are going to try to get more
than percentage points out of straight COPY.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Including PL/PgSQL by default
Next
From: Neil Conway
Date:
Subject: Re: code cleanup of timestamp code