Yaroslav
\copy (SELECT o.platform, o.platform_order_id, o.platform_created_at, o.extended_money_status, o.money_status, extended_delivery_status, delivery_status, synced_at FROM public.tbl_order o) TO /dev/null BINARY ;

COPY 77785892
Time: 2100811.503 ms (35:00.812)

35 минут бинари

сами  запросы копи  падают тк они долгие. на реплике

Да ну там скорее всего сетевой сторадж с latency под десятку миллисекунд. Технически иопсов тащит много, под СУБД становится тыквой.

Как-то долго, в самом деле...
А всего (с записью на диск) четыре часа, так?
Т.е. и дальше нужно искать (может, на тот же диск пишете? Или там всё-таки есть throttling? Как-то всё равно чтение медленнее, чем должно бы быть... или там другая нагрузка "съедает" IOPS-ы?).

теперь главный вопрос: что вы считаете в аналитике, ради которой готовы всю базу таскать?

тогда попробуйте всё же посмотреть в сторону КХ, который будет репликой для вашего ПГ. И уже из КХ будете делать необходимые запросы

https://github.com/mkabilov/pg2ch

pg_test_fsync девопсы так и не смогли найти?

pg2ch кажется имеет экспериментальный статус

Добавить kafka сбоку и прикрутить  через cdc репликацию из постгреса, решения уже существуют. Перекладывать нужное простым скриптом на питоне.

Или извернуться и написать свою прослойку сразу для bigquery. Но через kafka проще.

вроде да. но иногда это может быть единственным выходом...

Не вижу в этом всём rocket science. Заодно и от косяков периодичных обновлений избавляемся

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

ну мы не видим всей картины в целом)). Может там на этой же СУБД ещё 10-20 таблиц одновременно обновляются и аналогичные селекты идут.

без разницы, analyze более чем в два раза шустрее, так не может быть...

так и есть

поэтому и хотитм все олап запросы вынести в BQ

как по мне - так всё плохо. Сравниваю со своим baremetal, где для PG выделено 10Гб памяти и 3 ядра (nvme ssd):

5 seconds per test
O_DIRECT supported on this platform for open_datasync and open_sync.

Compare file sync methods using one 8kB write:
(in wal_sync_method preference order, except fdatasync is Linux's default)
        open_datasync                     20893.062 ops/sec      48 usecs/op
        fdatasync                         19866.136 ops/sec      50 usecs/op
        fsync                             19576.059 ops/sec      51 usecs/op
        fsync_writethrough                              n/a
        open_sync                         20798.804 ops/sec      48 usecs/op

Compare file sync methods using two 8kB writes:
(in wal_sync_method preference order, except fdatasync is Linux's default)
        open_datasync                     10445.704 ops/sec      96 usecs/op
        fdatasync                         16328.302 ops/sec      61 usecs/op
        fsync                             16295.395 ops/sec      61 usecs/op
        fsync_writethrough                              n/a
        open_sync                         10022.182 ops/sec     100 usecs/op

Compare open_sync with different write sizes:
(This is designed to compare the cost of writing 16kB in different write
open_sync sizes.)
         1 * 16kB open_sync write          9088.258 ops/sec     110 usecs/op
         2 *  8kB open_sync writes         6928.302 ops/sec     144 usecs/op
         4 *  4kB open_sync writes         4704.683 ops/sec     213 usecs/op
         8 *  2kB open_sync writes         2464.638 ops/sec     406 usecs/op
        16 *  1kB open_sync writes         1348.255 ops/sec     742 usecs/op

Test if fsync on non-write file descriptor is honored:
(If the times are similar, fsync() can sync data written on a different
descriptor.)
        write, fsync, close               17379.499 ops/sec      58 usecs/op
        write, close, fsync               17518.361 ops/sec      57 usecs/op

Non-sync'ed 8kB writes:
        write                            239796.913 ops/sec       4 usecs/op

так и есть - это наличие параллельной нагрузки аналогичного плана??