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
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? |