Мы не ставили перед собой цель как-то доработать коннектор от VMware. В greenplum_fdw своя реализация, и, как нам представляется, не самая удачная.
У нас свой коннектор, в который мы заложили бОльшую гибкость в плане подхода к определению обработчиков.
Да, это основное отличие, ориентированное на удобство пользователей. Еще пара опций касается пользователей, которые не хотят оценивать стомость выполнения запросов отдельным вызовом remote-кластера. Можно задать явно fdw_startup_cost, fdw_tuple_cost, чтобы влиять на итоговый план выполнения, если планировщик, допустим, строит какой-то неоптимальный план. Также можно конфигурировать размер батча (fetch_size) при обмене данными.
Касательно того, что в основе лежит подходящий и удобный механизма параллельных курсоров - так почему бы им было не воспользоваться и не городить что-то новое на уровне ядра.
В любом случае в рамках версии PostgreSQL 9.4 есть вполне определённый интерфейс FDW, в рамках которого тот же push-down делать было нецелесообразно. Такие варианты обсуждались на старте, но решили отложить до bump-а API в 7ке, где можно уже сделать больше фичей в этой части. В противном случае это был бы бэкпорт поддержки push-down для соединений и агрегатов (т.е. по сути, реализация нового API и перепахивание планировщика для поддержки таких вещей, как GetForeignJoinPaths, GetForeignUpperPaths и т.п).
Мы не ставили перед собой цель как-то доработать коннектор от VMware.
В greenplum_fdw своя реализация, и, как нам представляется, не самая удачная.
У нас свой коннектор, в который мы заложили бОльшую гибкость в плане подхода к определению обработчиков.
Да, это основное отличие, ориентированное на удобство пользователей. Еще пара опций касается пользователей, которые не хотят оценивать стомость выполнения запросов отдельным вызовом remote-кластера. Можно задать явно fdw_startup_cost, fdw_tuple_cost, чтобы влиять на итоговый план выполнения, если планировщик, допустим, строит какой-то неоптимальный план. Также можно конфигурировать размер батча (fetch_size) при обмене данными.
Касательно того, что в основе лежит подходящий и удобный механизма параллельных курсоров - так почему бы им было не воспользоваться и не городить что-то новое на уровне ядра.
В любом случае в рамках версии PostgreSQL 9.4 есть вполне определённый интерфейс FDW, в рамках которого тот же push-down делать было нецелесообразно. Такие варианты обсуждались на старте, но решили отложить до bump-а API в 7ке, где можно уже сделать больше фичей в этой части. В противном случае это был бы бэкпорт поддержки push-down для соединений и агрегатов (т.е. по сути, реализация нового API и перепахивание планировщика для поддержки таких вещей, как GetForeignJoinPaths, GetForeignUpperPaths и т.п).