Re: FDW, too long to run explain

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Vijaykumar Jain <vjain(at)opentable(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: FDW, too long to run explain
Date: 2019-02-17 19:09:16
Message-ID: 31633.1550430556@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> A question for the PostgreSQL hackers would be, Is it necessary and
> desirable that the EXPLAIN be issued in the same transaction as the
> eventual DECLARE and FETCHes? I don't think it is.

It seems like a good idea to me. I certainly don't think "I've got
an idle-in-transaction timeout on the remote that's shorter than my
local transaction runtime" is a plausible argument for changing that.
You could trip over that with a slow query regardless of whether we
separated the EXPLAIN step, just because there's no guarantee how
often we'll ask the FDW to fetch some rows.

> I guess if the foreign
> side table definition got changed between EXPLAIN and DECLARE it would
> cause problems, but changing the foreign side definition out of sync with
> the local side can cause problems anyway, so is that important to preserve?

I believe that the EXPLAIN will leave the remote transaction holding
AccessShareLock on the query's tables, meaning that doing it in one
transaction provides some positive protection against such problems,
which we'd lose if we changed this.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Jeff Janes 2019-02-17 19:26:17 Re: [External] Re: FDW, too long to run explain
Previous Message Jeff Janes 2019-02-17 18:58:47 Re: FDW, too long to run explain