Re: lag() default value ignored for some window partition depending on table records count?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Loïc Revest <l(dot)revest(at)apc(dot)fr>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: lag() default value ignored for some window partition depending on table records count?
Date: 2022-04-26 22:35:54
Message-ID: 276587.1651012554@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

=?UTF-8?B?TG/Dr2MgUmV2ZXN0?= <l(dot)revest(at)apc(dot)fr> writes:
> Long story short:
> - We track history data in a partitioned table which boils down to "key
> fields + a JSONB data column", the latter being a list of date/numeric
> values pair ;
> - For every of this date/numeric couple within their "window partitioning",
> we need to determine the preceding value, thus the use of lag(<value>, 1,
> 0::numeric), since it's relevant for us here to get the very first record
> of the partition having "0.00" as its preceding value;
> - Except that the "first" row of some partitions gets NULL instead of
> 0::numeric as the result of lag(<value>, 1, 0::numeric), while other get
> 0::numeric as expected;

Hm ...

> Attached is the test case database script we've been able to reproduce the
> "issue" one hundred percent of the time on, but without the data - even
> after compression this weights ∼8.5Mb. Data that I'd happily share would
> anyone points me towards the customary way to do it here with such "big" a
> file.

With no data, this is pretty pointless. Maybe you could make a script
to fill the tables with some dummy data that reproduces the problem?

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message David G. Johnston 2022-04-26 22:48:01 Re: lag() default value ignored for some window partition depending on table records count?
Previous Message Loïc Revest 2022-04-26 22:25:36 lag() default value ignored for some window partition depending on table records count?