On Mon, Feb 10, 2020 at 4:39 PM Tom Lane wrote:
>
> Well, it's not that hard to get rid of that scalar sub-select: since
> you're already relying on current_rollup to produce exactly one row,
> you could write a plain join instead, something like
>
Using a join instead of the sub-select did alrea
Using a column to mark rolled up rows might have been a better choice, but
there are unfortunately some regulatory requirements
that require that table to be immutable. I'm not sure about the
implications w.r.t. auto vacuum, which is already a consideration for us
due to the sheer size of the table
On Mon, Feb 10, 2020 at 11:34:01AM +0100, Chris Borckholder wrote:
> I have a large table of immutable events that need to be aggregated
> regularly to derive statistics. To improve the performance, that table is
> rolled up every 15minutes, so that online checks can aggregate rolled up
> data and
Chris Borckholder writes:
> When using a sub select or CTE to get the latest roll up time, the query
> planner fails to recognize that a most of the large table would be filtered
> out by the condition and tries a sequential scan instead of an index scan.
> When using the literal value for the WHE
Hi,
I have a large table of immutable events that need to be aggregated
regularly to derive statistics. To improve the performance, that table is
rolled up every 15minutes, so that online checks can aggregate rolled up
data and combine it with latest events created after the last roll up.
To impl
