> I see an estimate for 1000 rows in your EXPLAIN output too, so you're
experiencing the same
> although in your case the estimate of 1000 might be more accurate. The
misestimation was causing
> significant performance problems for me.
> My solution was to wrap generate_series() in a custom functi
> On Nov 8, 2023, at 8:26 PM, Lincoln Swaine-Moore
> wrote:
>
> Hi all--
>
> I'm having a performance problem in 12.16 that I'm hoping someone can help
> with.
> Thanks for any and all help and suggestions.
Hi Lincoln,
I haven't read your SQL carefully so I may be completely off base,
> Maybe doesn't help overall but this can be equivalently written as:
s + '1 day'::interval as period_end
Ah, so I've glossed over a detail here which is that I'm relying on some
timezone specific behavior and not actually generate_series itself. If
you're curious, the details are here:
https://ww
On Wed, Nov 8, 2023 at 6:26 PM Lincoln Swaine-Moore
wrote:
> SELECT
>
s at time zone 'utc' AS period_start,
> LEAD(s) OVER (
> ORDER BY
> s
> ) at time zone 'utc' AS period_end
>
Maybe does
Hi all--
I'm having a performance problem in 12.16 that I'm hoping someone can help
with.
I have a table shaped roughly like this:
Table "public.data"
Column |Type | Collation | Nullable |
Default
--
