Re: Soon-to-be-broken regression test case - Mailing list pgsql-hackers

From David Rowley
Subject Re: Soon-to-be-broken regression test case
Date
Msg-id CAKJS1f_0A42gP94CWduAamThYWdY6=VeUZ0u4RvnOPbDiDWA1w@mail.gmail.com
Whole thread Raw
In response to Re: Soon-to-be-broken regression test case  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Soon-to-be-broken regression test case  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 12 October 2018 at 05:52, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> On 2018-Oct-11, Tom Lane wrote:
>
>> Hm, I'm not seeing any regression test result changes there.  However,
>> if you're just executing queries and not EXPLAIN'ing them, it's possible
>> something unwanted is happening under the hood.
>
> Hmm, no, the explains are there.  Here's one example -- maybe your new
> planner smarts do not change these plans for some reason (I note that
> you mentioned EXISTS in your OP, which this one does not use; I further
> note that we don't use EXISTS anywhere in partition_prune.sql, which
> probably amounts to uncovered cases):
>
> prepare ab_q2 (int, int) as
> select a from ab where a between $1 and $2 and b < (select 3);

I guess if we ever did something to break that then we'd need to not
do anything when there are volatile functions present.  If people are
writing that then probably they're doing so to trick the planner,
perhaps to hide some stats that get outdated easily. I'd imagine we'd
upset more people than we'd please.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel
Next
From: Christoph Berg
Date:
Subject: Re: Debian mips: Failed test 'Check expected t_009_tbl data onstandby'