Re: pg_dump additional options for performance

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_dump additional options for performance
Date: 2008-02-26 20:03:47
Message-ID: 7088.1204056227@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Joshua D. Drake" <jd(at)commandprompt(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Neil Conway 2008-02-26 20:06:39 Re: code cleanup of timestamp code
Previous Message Tom Lane 2008-02-26 19:55:34 Re: code cleanup of timestamp code