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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
