Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly - Mailing list pgsql-hackers

From Tom Lane
Subject Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly
Date
Msg-id 21358.1520229112@sss.pgh.pa.us
Whole thread Raw
In response to Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Responses Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> writes:
> On Mon, Mar 5, 2018 at 8:51 AM, Etsuro Fujita
> <fujita.etsuro@lab.ntt.co.jp> wrote:
>> Totally outdated stats used in query planning causes the failures? ANALYZE
>> right before the plan-changing queries would fix the failures?

> I think the testcase file for postgres_fdw has grown really large over
> the time, as we have added more pushdown. Since most of the queries in
> that file use the same tables created at the beginning of the file,
> changes somewhere in-between (esp. DMLs) affect the following queries.
> It's getting hard to add a test query in that file and expect stable
> results.

The thing that I find curious, now that we've shut off autovacuum
altogether on those tables, is that we *still* aren't getting stable
results.  How can that be?  Yeah, if you add another query in the middle
you might find that changing later results, but for any fixed contents of
the test script, why isn't the buildfarm getting the same answers that the
patch author and committer got?  I could believe different results on
32-bit and 64-bit hardware, but that does not seem to be quite the pattern
we're seeing.

> I think, it's time to split the file into at least two one
> for queries and one for DMLs.

That seems largely irrelevant right at this point.  First we have to
explain the instability.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Abhijit Menon-Sen
Date:
Subject: Re: Incorrect use of "an" and "a" in code comments and docs
Next
From: Amit Langote
Date:
Subject: Re: [HACKERS] path toward faster partition pruning