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.
Comments
Thank you for your interest!
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.
For example, you can look at the imap foreign data wrapper (https://github.com/Kozea/Multicorn/blob/master/python/multic...) to see how the conditions from postgresql are converted to an IMAP filter, allowing for server side filtering.
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.
Thank you for the explanation. I don't have an immediate need for this, but it's an interesting approach. Good luck!