Pull to refresh

Comments 16

Скачать исправленную версию mysql_fdw можно отсюда: https://github.com/PostgreSQLpro/mysql_fdw

Тут 404…

Спасибо, Алексей, исправил

Помнится лет 15 назад нам нужно было интегрировать phpBB в какой-то сайт, который крутился на PostgreSQL. Сам phpBB работал на mysql'e и нужно было добавлять в его базу новых пользователей, которые зарегались на головном сайте. Так вот, ничего лучшего мы не придумали как подключить к Постгресу Perl, написать на перле хранимую постгресовскую процедуру, которая вызывалась триггером при вставке нового юзера в базу, которая посредством curl дергала PHPшный скрипт, который в свою очередь добавлял нового юзера. Затем по всей этой цепочке возвращался ответ и парсился в перле, который при ошибке выдавал её наверх и уже в PHP скрипте мы разруливали эту ошибку…
#суровоеИТ :)
в качестве дополнения. обращение из текущей БД PostgreSQL к другой БД этого же PostgreSQL, даже внутри одного сервера, тоже приходится делать через FOREIGN TABLE. неприятно, что «чужие» таблицы не видны в общем списке таблиц.

Это известная проблема, что PostgreSQL прикидывается, что не видит соседние бд, но при этом кластер использует общий xid, shared buffers и тд и тп.

Подскажите пожалуйста, как сейчас PostgreSQL узнаёт статистику данных в foreign table, чтобы выбрать правильный план в случае с join?

Это никак не предусмотренно. Вы можете изменить свой запрос для удаленного сервера, чтобы он эффективнее выполнялся.

Как-нибудь ещё, кроме как завернув в функцию с указанием rows, можно дать планировщику понять, сколько данных в foreign table?

вы абсолютно правы, надо сделать функции под типичные запросы, другого способа подсказать планеру нет (как и хинтов). скорее всего сообщество не пойдет на подобные "хинты", а реализовать подобное без поддержки ядра не возможно.

А решает ли это https://habrahabr.ru/post/169751/?
Можно ли им прокинуть статистику?

Александр — мой руководитель, и ему под силу написать в ядро патчи, которые необходимы. Но если это не примут в ядро (а хинтов нет в ядре), то поддерживать компанией пачку таких расширений на голом энтузиазме невозможно.

В случае, если допустИм некоторый лаг по времени (ну и очевидные накладные расходы), можно натянуть materialized view на FDW и получить весь профит статистики, собственных индексов (в том числе GIN/GiST, которых в MySQL, на сколько я помню, толком нет) и прочих прелестей постгреса.

Почему вы рекомендуете make install, даже не checkinstall, не говоря уже о сборке пакета дистрибутива? :)
Как правильно пакетировать экстеншены для постгреса?

Потому что я администратор, я собрал не одну сотню пакетов под разные дистрибутивы, и не рекомендую превращать рабочую машину в мусор. Cоветую поддержку повесить все-таки на плечи администратора или дистрибутива. А администратору контролировать права на сервере :)
Но перед тем, как это окажется на вашем сервер, вы должны попробовать локально, как — описано в статье.

Правильно ли я понимаю, что в первой части вы описываете как заставить работать pushdown из FDW для join'а? Если да, то есть ли планы рассказать подробнее об этом механизме, быть может, на примере различных FDW?

Sign up to leave a comment.