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

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Vijaykumar Jain <vjain(at)opentable(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 21:00:15
Message-ID: CAMkU=1z4JOa1bfGZuttzLPvFF9zCaH9MW8fUs29Xd5ouaNoCfw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sun, Feb 17, 2019 at 2:37 PM Vijaykumar Jain <vjain(at)opentable(dot)com> wrote:

>
> Ok, i raked this from the logs where enabled log_min_duration_statement =
> 10s
>
> 2019-01-31 12:48:18 UTC LOG: duration: 29863.311 ms statement: EXPLAIN
> SELECT blah, FROM public.view WHERE ((scheduled_bdt >= '2019-01-20'::date))
> AND ((scheduled_bdt <= '2019-01-26'::date)) AND ((somekey = ANY
> ('{269029,123399,263164,261487}'::bigint[]))) (both the columns are
> indexed)
>

That is interesting. Was that in the logs for the local or the foreign
side? And is it common, or rare?

If on the local side, could it be that the EXPLAINs sent to the foreign
side are being made to wait by the connection pooler, leading to long
delays? If that is from the foreign side, then it should be conceptually
unrelated to FDW. Any chance you could reproduce the slowness in your test
environment? Slowness in the planner is probably related to the schema
structure, not the data itself.

I don't think this would be related to the idle-in-transaction, except that
one FDW connection maybe idle-in-transaction after its EXPLAIN is done
because it is waiting for another FDW connection to slowly run its EXPLAIN.

Cheers,

Jeff

>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Vijaykumar Jain 2019-02-17 21:14:44 Re: [External] Re: FDW, too long to run explain
Previous Message auxsvr 2019-02-17 19:43:05 Re: FDW, too long to run explain