Wow, switching from Python to Lisp produced a shocking speedup. I liked Lisp in college but I probably never would have considered it nowadays... If I wanted a quick runtime, I probably would have fallen for Go or Julia or, after some maturing, Rust.
Lisp has a big historical advantage coming from it being the 2nd oldest surviving computer language after FORTRAN, it got started in 1957 on a vacuum tube computer.
While seldom as fast as e.g. FORTRAN let alone assembly (there was a period when MACLISP was faster at numerical code than DEC's PDP-10 FORTRAN, but that was at least as much due to DEC), to be fast enough on the old, slow hardware of its founding first couple of decades hackers had to figure out how to make it pretty fast on an absolute scale. E.g. they've been working on garbage collection for 55 years (!).
So compared to languages like Python and its various implimentations, you shouldn't be surprised if there are Lisps out there that are faster.
All that said, it's easy to quickly write a slow Lisp; a fast Lisp requires on the order of as much work as making a fast implementation of anything else. So caveat emptor ^_^.
As for languages like Rust, I think they're complimentary, and that a programmer ideally should at minimum be fluent in one systems programming language like C or Rust and one high level GCed language like Lisp, Python, Go, Ruby, Julia, Lua, etc. etc. etc. (Modern JITed Java kinda splits the difference; a contrarian would say it combines the productivity of C++ and the speed of a GCed language.)
Well, the SBCL code includes code for literally generating assembly code specific to x86-64 to get that performance and is 3 times as long as Python. Presumably the inline assembly code is not part of any LISP standard but highly specific to that specific LISP implementation.
I'm told by one of the FOSDEM PGDAY conference organizers: "I believe they won't be". Sorry about that. The slides are going to be available on http://tapoueh.org/ and http://pgloader.io/ though.
Well we can consider that pgloader already implements the first half of the streaming replication: the base copy to stream changes onto.
Adding support for the MySQL binlog replication format is on the TODO list, if you're proficient in it I would welcome hints to implement it correctly.
In terms of priority and organisation, it's Open Source so you know how it works right? Contributions are welcome, as are feature based sponsoring.
You have self-contained binary files allowing you to play with /usr/bin/pgloader (or ./pgloader) without having to know anything about Common Lisp.
Enjoy ;-)