Conditional lead/lag function PostgreSQL?

Your definition:

activity from group B always takes place after activity from group A.

.. logically implies that there is, per user, 0 or 1 B activity after 1 or more A activities. Never more than 1 B activities in sequence.

You can make it work with a single window function, DISTINCT ON and CASE, which should be the fastest way for few rows per user (also see below):

SELECT name
     , CASE WHEN a2 LIKE 'B%' THEN a1 ELSE a2 END AS activity
     , CASE WHEN a2 LIKE 'B%' THEN a2 END AS next_activity
FROM  (
   SELECT DISTINCT ON (name)
          name
        , lead(activity) OVER (PARTITION BY name ORDER BY time DESC) AS a1
        , activity AS a2
   FROM   t
   WHERE (activity LIKE 'A%' OR activity LIKE 'B%')
   ORDER  BY name, time DESC
   ) sub;

db<>fiddle here

An SQL CASE expression defaults to NULL if no ELSE branch is added, so I kept that short.

Assuming time is defined NOT NULL. Else, you might want to add NULLS LAST. Why?

(activity LIKE 'A%' OR activity LIKE 'B%') is more verbose than activity ~ '^[AB]', but typically faster in older versions of Postgres. About pattern matching:

Conditional window functions?

That’s actually possible. You can combine the aggregate FILTER clause with the OVER clause of window functions. However:

  1. The FILTER clause itself can only work with values from the current row.

  2. More importantly, FILTER is not implemented for pure genuine functions like lead() or lag() (up to Postgres 13) – only for aggregate functions.

If you try:

lead(activity) FILTER (WHERE activity LIKE 'A%') OVER () AS activity

Postgres will tell you:

FILTER is not implemented for non-aggregate window functions

About FILTER:

Performance

For few users with few rows per user, pretty much any query is fast, even without index.

For many users and few rows per user, the first query above should be fastest. See:

For many rows per user, there are (potentially much) faster techniques, depending on details of your setup. See:

Leave a Comment