Re: generate_series regression 9.6->10

From: Andres Freund <andres(at)anarazel(dot)de>
To: Paul Ramsey <pramsey(at)cleverelephant(dot)ca>
Cc: Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: generate_series regression 9.6->10
Date: 2017-05-24 17:23:57
Message-ID: 20170524172357.tv3ti66foeaw5w3k@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2017-05-24 10:09:19 -0700, Paul Ramsey wrote:
> The behaviour of generate_series seems to have changed a little, at least
> in conjunction w/ CTEs. Under 9.6 (and prior) this query returns 2127 rows,
> with no nulls:
>
> with
> ij as ( select i, j from generate_series(1, 10) i, generate_series(1, 10)
> j),
> iijj as (select generate_series(1, i) as a, generate_series(1, j) b from ij)
> select a, b from iijj;
>
> Under 10, it returns only 715 rows, with many nulls.

Right, that's expected - we probably need to expand on that in the
release notes. Before v10 targetlist with multiple SRFs were evaluated
using on a "least common multiple" logic. I.e. if you have SELECT
generate_series(1,2), generate_series(1,4); once the first SRFs is
exhausted it was restarted. Only once all SRFs stopped returning rows
at the same time, things were stopped. Going on forward, once either
SRF stops returning rows, it'll return NULL until all SRFs are
exhausted.

Makes sense? Is that a problem for you? If so, what do you use the LCM
logic for in practical terms?

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-05-24 17:28:11 Re: generate_series regression 9.6->10
Previous Message Christoph Berg 2017-05-24 17:09:21 Re: 10beta1 sequence regression failure on sparc64