On 16/06/2020 18:28, Marc Cousin wrote:
> Oh, sorry about that, I forgot to detail this. I tested on both 10.13 (which
> is the production environment on which we faced this), and on 12.3, with the
> same problem.
>
> On 16/06/2020 17:51, Tom Lane wrote:
>> Marc Cousin writes:
>>> Of course, wh
Oh, sorry about that, I forgot to detail this. I tested on both 10.13 (which is
the production environment on which we faced this), and on 12.3, with the same
problem.
On 16/06/2020 17:51, Tom Lane wrote:
> Marc Cousin writes:
>> Of course, what happens here is that the histogram says that max(
Marc Cousin writes:
> Of course, what happens here is that the histogram says that max(a) is
> 100, and get_actual_variable_range verifies the real upper bound. And has
> to read quite a few dead index records.
We've revised that logic several times to reduce the scope of the
problem. Sinc
Hi,
We're having an issue with planner performance when doing large deletes at the
same time as we have long running transactions, from what we gathered, because
of the scan to find the actual minimum and maximum values of the table.
Instead of trying to explain what happens, here is a very sim