Re: [External] Re: FDW, too long to run explain

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

In response to

Responses

Browse pgsql-general by date

  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