From: | Vijaykumar Jain <vjain(at)opentable(dot)com> |
---|---|
To: | auxsvr <auxsvr(at)gmail(dot)com> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: [External] Re: FDW, too long to run explain |
Date: | 2019-02-17 11:32:08 |
Message-ID: | CAE7uO5hLPJDbqY3EpaPjAduoYf7t07snp=bfOH-_BTN=+u9RYA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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(at)gmail(dot)com> 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
>
>
>
> --
Regards,
Vijay
From | Date | Subject | |
---|---|---|---|
Next Message | Ravi Krishna | 2019-02-17 16:06:39 | Re: WSL (windows subsystem on linux) users will need to turn fsync off as of 11.2 |
Previous Message | auxsvr | 2019-02-17 10:57:04 | Re: FDW, too long to run explain |