Crap, I'm working on something exactly like this :D Was about to upload it to Github just today, but still wanted to fix a few things.
Yours looks quite more finished, one thing that would be very useful is handling Python to Postgres type conversion, like PL/Python does. After that, the next step is caching I/O functions for the duration of the scan, which PL/Python also does.
Nice to see that the idea made sense for more than one person, hope Multicorn will rock!
Actually, the ideal thing to happen would be for PL/Python to somehow become a shared library that provides the typecasting routines, but I'm afraid that's a very big task and difficult to get accepted upstream. It's sad that PL/Python already includes all the code you need to transform Python lists to Postgres arrays, bools to PG bools and so on and every project like this one has to duplicate all that logic.
BTW: in my approach I opted for passing the entire Qual node as a string (using nodeToString) and my plan was to write a Python parser for that format that takes a string and returns a Python object. Not sure how hard that will turn out.
But what kind of performance is it possible to get with complex queries on these external sources? Does the PG server need to load all the data in memory from the source to do filters, joins and sorts?
The postgresql plan is parsed, and passed as a list of "quals", objects representing simple filters.
As an implementer, you don't HAVE to enforce those, since postgresql will recheck them for you anyway, but they can be quite handy.
The required columns are also provided, so if you don't need the email payload, the foreign data wrapper will not fetch it.
For joins, it will depend on the execution plan.
There is still plenty of work on parsing the postgresql execution plan into something more useful, but the current set of "optimizations" is sufficient for our main use cases.
Yours looks quite more finished, one thing that would be very useful is handling Python to Postgres type conversion, like PL/Python does. After that, the next step is caching I/O functions for the duration of the scan, which PL/Python also does.
Nice to see that the idea made sense for more than one person, hope Multicorn will rock!