Re: Rows From but with Subqueries (or a cleaner non-array-using alternative)?

From: Michael Lewis <mlewis(at)entrata(dot)com>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Rows From but with Subqueries (or a cleaner non-array-using alternative)?
Date: 2022-02-15 06:03:23
Message-ID: CAHOFxGqfT8vDAx0LtOv+osgmUnbFmH8XvhP2-PfBo8ZQENmDug@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

In pseudo code, group_index is defined as:
case when LAG(v) OVER (ORDER BY i) = v then lag(i) ELSE i END, right?

If you have that in the first cte instead of the start/end business, then
you can just select vals, group number, and row_num over that new grouping,
right?

Something like this?

WITH vals (i,v) AS (VALUES
(0,1),(1,0),(2,0),(3,1),(4,0),(5,0),(6,1),(7,1),(8,0),(9,1)),
grouped_vals AS (SELECT *,
case when LAG(v) OVER (ORDER BY i) = v then lag(i) OVER (ORDER BY i) ELSE i
END AS group_index
FROM vals
)
select *, row_number() OVER (PARTITION BY group_index ORDER BY i)
from grouped_vals
where v = 0;

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Shaozhong SHI 2022-02-15 06:23:59 Turn a json column into a table
Previous Message Michael Lewis 2022-02-15 05:44:11 Re: increasing effective_cache_size slows down join queries by a factor of 4000x