From: | Marc Cousin <cousinmarc(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: slow get_actual_variable_range with long running transactions |
Date: | 2020-06-16 16:37:17 |
Message-ID: | 42efd5ff-aa9d-0ff9-58b8-f7d5ddeb5468@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 <cousinmarc(at)gmail(dot)com> writes:
>>> Of course, what happens here is that the histogram says that max(a) is 1000000, 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. Since you didn't say which PG version you're using exactly,
>> it's hard to offer any concrete suggestions. But I fear there's
>> not a lot you can do about it, other than upgrading if you're on a
>> pre-v11 release.
>>
>> regards, tom lane
>>
>
As you told me this I did some more tests on PG 12.
The first attempt is the same (maybe some hints being set or something like that), the second is much faster. So nothing to see here, sorry for the noise.
And sorry for the previous top posting :)
Regards
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2020-06-16 16:47:07 | Re: language cleanups in code and docs |
Previous Message | Marc Cousin | 2020-06-16 16:28:01 | Re: slow get_actual_variable_range with long running transactions |