On 25.11.2020 18:12, Tom Lane wrote:
> Mats Julian Olsen <mats@duneanalytics.com> writes:
>> On 25.11.2020 17:58, Tom Lane wrote:
>>> ... Have you tried looking into pg_locks on the
>>> remote server while this query is running?
>> Thanks Tom, I'll try to spin up a regular Postgres instance on both rds
>> and ec2 and see if that helps. As for the locks, I can not see any
>> blocked activity on the remote server while the query runs.
> Another place to check is pg_stat_activity, specifically wait_event_type
> and wait_event.
Thanks Tom, I've now setup the fdw from a local postgres instance and
seeing similar timings for the selects and inserts.
I've got some more numbers here:
x (aurora aws eu-west-1) => y (gcp gce us-central-1): ~15 s
local (eu) => y: ~15 s
local (eu) => test 1 (postgres aws rds eu-west-1): ~4 s
local (eu) => test 2 (postgres google cloud sql, us-central-1): ~15s
local (eu) => local (eu): < 1s
SELECTs in all instances are sub-second.
To me this does indicate some sort of networking issue, but I'm
wondering if INSERTs are treated differently than SELECTs in
postgres_fdw? The only feasibly explanation I have is that postgres_fdw
does many more network calls for INSERT than for SELECT, e.g. something
like 1 for SELECT and `n` for INSERT?
Best,
Mats
