Re: COPY speedup

Pierre Frédéric Caillaud escribió:

> But when I see a big red button, I just press it to see what happens.
> Ugly hacks are useful to know how fast the thing can go ; then the
> interesting part is to reimplement it cleanly, trying to reach the
> same performance...

Right -- now that you've shown a 6x speedup increase, it is clear that
it makes sense to attempt a reimplementation.  It also means it makes
sense to have an additional pair or two of input/output functions.


> >Maybe add new methods, fastrecv/fastsend etc.  Types that don't
> >implement them would simply use the slow methods, maintaining
> >backwards compatibility.

> I considered doing it like this, but it is a lot more work : adding
> entries to the system catalogs, creating all the new functions,
> deciding what to do with getTypeBinaryOutputInfo (since there would
> be 2 variants), etc. Types that don't support the new functions
> would need some form of indirection to call the old functions
> instead, etc. In a word, doable, but kludgy, and I would need help
> from a system catalog expert.

Right.

> Also, on upgrade, information about the new functions must be inserted
> in the system catalogs ? (I don't know how this process works).

No, that's not how pg_migrator works.  Catalog upgrades are handled by
pg_dump/pg_restore, so you don't need to worry about it at all.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support