Re: slow get_actual_variable_range with long running transactions

2020-06-16 Thread Marc Cousin
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

Re: slow get_actual_variable_range with long running transactions

2020-06-16 Thread Marc Cousin
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(

Re: slow get_actual_variable_range with long running transactions

2020-06-16 Thread Tom Lane
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

slow get_actual_variable_range with long running transactions

2020-06-16 Thread Marc Cousin
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