On Fri, 30 Aug 2024 at 23:45, Rumpi Gravenstein wrote:
> Here's the output of the script you requested.
>
These results look correct to me. Not the same as the ones you originally
reported.
David
Wait...I see my issue. Duh! The where clause is applied after the CTE is
evaluated
On Fri, Aug 30, 2024 at 7:37 AM Rumpi Gravenstein
wrote:
>
> that the lag() functions are seeing some rows that don't show up in
> the final output.
>
>
> I'm under the impression that the predicate filter is
that the lag() functions are seeing some rows that don't show up in
the final output.
I'm under the impression that the predicate filter is applied before the
analytic is evaluated. Are you suggesting that I have this wrong -- the
analytic is evaluated and then the filter is applied?
On Thu, A
On Fri, 30 Aug 2024 at 11:18, Rumpi Gravenstein wrote:
>
> Which returns:
> logical_partition_keyusage_texttxtrpo_txtindxmx_indxprvnxtnxt2prv2prv3
> "TEST_DATA"
> "F(T61)(EXPORT)" "F(T61)(EXPORT)" "F" "1" "7" *"F"* "(" "(" "[NULL]"
> "[NULL]"
> "TEST_DATA"
> "F(T61)(EXPORT)" "F(T61)(EXPORT)" "("
Rumpi Gravenstein writes:
> Is this a PostgreSQL bug?
Maybe, but you haven't provided enough information to let anyone else
reproduce the behavior.
Personally I'm suspicious that because your lag() calls are over
partition by p.logical_partition_key, p.txt order by indx
but then you filter
Experts,
I am running on
PostgreSQL 14.13 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0
20210514 (Red Hat 8.5.0-22), 64-bit
I have the following query which returns what I expect:
with
d(logical_partition_key, model_usage) as ( values( 'TEST_DATA' ,
'F(T61)(EXPORT)' )
)
,
usg_txt as