On 9/17/25 16:57, Frédéric Yhuel wrote:
> Yes, Laurenz made a similar suggestion, but the problem is that I'm
> mostly interested in the estimated number of output rows... because in
> the real query, there's a very bad Hash Join above (the Nested Loop is
> *much* faster).
BTW, I've also tested another solution: partitioning on 'criticity',
with one partition for 'INFO' (99% of the rows), and another one for the
other values ('WARNING' and 'ALARM' in the real case). The statistics
are much better... however an expression index would be an easier fix.
Multivariate MCV statistics don't work well in the real case (100M lines
in the table).