Как легче начать работать с PostgreSQL имея опыт в MySQL?

Если имеются ввиду сами СУБД, то ничего лучше чтения мануалов по настройке и оптимизации предложить сложно.
Впрочем и различия в SQL диалектах проще всего изучать тем же путем.

В свое время, когда передо мной стояла такая же задача, мне хватило пары часов просмотра по диагонали официальной документации + php.net для уточнения особенностей взаимодействия с СУБД средствами PHP.

Хотя если под "подружиться с PostgreSQL" имелся еще и PL/pgSQL, то все далеко не так тривиально, но опять же в роли стартовой точки я бы предложил именно http://www.postgresql.org

Используйте ORM :)

http://ru.wikipedia.org/wiki/ORM

аналог show tables \dt
аналог show fields from table \d table
консолька: psql -U postgres база
выход из нее \q )
вместо limit x,y limit x offset y (возможно спутал места x и y)
вместо автоинкремента serial и bigserial
Работа с датой другая немного (что то в кавычки надо заключать не помню точно)
Куча индексов для этого манул надо читать
Полнотекстовый поиск (с версии 8.3, поможет только манул)

Это так в двух словах с чем я столкнулся), остальное за меня ActiveRecord делает

ОООО блин помниться я работал с ней лет 5 назад.
Тогда реально парился с инкрементальными полями. Слава богу тот опыт остался в прошлом, сейчас я на mysql сижу. Хотя слышал что Постгрес оч сильно продвинулся в масштабировании.

Вобщем эта штука называется SEQUENCE. Она создается отдельно. А потом используется для поля в твоей таблице. Чет это мне оракл напоминает.

Вобщем правильно народ грит посмотри в сторону ORM и не парься.
Или рискни ADODB для PHP, Hybernate для Java.

А как же быть с заменой SQL_CALC_FOUND_ROWS mysql в postgres? Это подсчет найденных строк по запросу без учета limit. Сегодня выяснил, что аналога в постгри нет. Предложили юзать курсоры, но в web-приложении так не получится. Делать 2 одинаковых запроса, первый из которых делает count(*), а второй тянет записи по limit слишком затратно, если используются сортировка: время увеличится почти в 2 раза. Может на админке с ORM на это и плевать, но на фронтэнде самое важное — скорость.

Я глубоко я не копал - в основном поверхностные отличия и различия в DQL которые уже упомянуты были. Из интересного что находил я у себя писал ( http://kurapov.name/technology/web/datab… ), а вот во внутренности того как на физическом уровне работает СУБД, индексы и как работает трансляция в поиск по индексам - этого я и с mysql толком не знаю. Максимум EXPLAIN :)

Для блог-движка использую адаптер как и для mysql, который упрощает работу ( типа ActiveRecord ), но
поскольку функции многие всё-равно отличаются (даты) то лёгкой миграции не получится. AdoDB использовал раньше при миграции на Oracle, много плевался но тогда этот тяжеловес спас положение.