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