Re: slow get_actual_variable_range with long running transactions
Вложения
В списке pgsql-hackers по дате отправления:
| От | Marc Cousin |
|---|---|
| Тема | Re: slow get_actual_variable_range with long running transactions |
| Дата | |
| Msg-id | 42efd5ff-aa9d-0ff9-58b8-f7d5ddeb5468@gmail.com обсуждение |
| Ответ на | Re: slow get_actual_variable_range with long running transactions (Marc Cousin <cousinmarc@gmail.com>) |
| Список | 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 wefaced this), and on 12.3, with the same problem. > > On 16/06/2020 17:51, Tom Lane wrote: >> Marc Cousin <cousinmarc@gmail.com> writes: >>> Of course, what happens here is that the histogram says that max(a) is 1000000, and get_actual_variable_range verifiesthe 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 nothingto see here, sorry for the noise. And sorry for the previous top posting :) Regards
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера