| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: PGOPTIONS="-fh" make check gets stuck since Postgres 11 |
| Date: | 2019-07-09 02:20:52 |
| Message-ID: | 16391.1562638852@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Michael Paquier <michael(at)paquier(dot)xyz> writes:
> On Mon, Jul 08, 2019 at 03:21:41PM -0400, Tom Lane wrote:
>> Having said that, join_hash.sql in particular seems to have zero
>> value if it's not testing hash joins, so I think it'd be reasonable
>> for it to override a global enable_hashjoin = off setting. None of
>> the other regression test scripts seem to take nearly as much of a
>> performance hit from globally forcing poor plans.
> I am a bit confused here. Don't you mean to have enable_hashjoin =
> *on* at the top of hash_join.sql instead like in the attached?
Right, overriding any enable_hashjoin = off that might've come from
PGOPTIONS or wherever.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2019-07-09 02:22:13 | Re: PGOPTIONS="-fh" make check gets stuck since Postgres 11 |
| Previous Message | Jamison, Kirk | 2019-07-09 02:12:18 | RE: [PATCH] Speedup truncates of relation forks |