I am yet to figure out the reason, what we have done is implement fake columns to represent samples and giving them random numbers and keeping other bulls to fake limit.
Most of the queries that were impacted were the ones that did not push order by and limit to foreign servers.
I am also trying to upgrade pg11 to make use of parallelisation.
For now I am making use of materialised view on each shard and using predicates that get pushed directly to ensure a simple plan is created.
There is a compromise but this is what is reasonable for now.
On Sun, 17 Feb 2019 at 4:27 PM auxsvr <auxsvr@xxxxxxxxx> wrote:
Related to this question:
Postgresql cursors are in most cases I've tried extremely slow. The cause is as described in my previous answer, in my experience. Is there any plan or way to improve this situation? For example, for FDW one would expect the plan on the remote side to be similar, if not identical, to the one locally, with the exception of the setup cost.
--
Regards,
Peter
Vijay
