Re: Difference in execution plans pg12 vs pg14

Поиск
Список
Период
Сортировка
От Peter J. Holzer
Тема Re: Difference in execution plans pg12 vs pg14
Дата
Msg-id 20211211111818.7h3o5zbywhfjzvgf@hjp.at
обсуждение исходный текст
Ответ на Difference in execution plans pg12 vs pg14  (Дмитрий Иванов <firstdismay@gmail.com>)
Ответы Re: Difference in execution plans pg12 vs pg14  (Дмитрий Иванов <firstdismay@gmail.com>)
Список pgsql-general
On 2021-12-11 06:00:40 +0500, Дмитрий Иванов wrote:
> Afternoon. I was able to make the necessary changes to my base needed to
> migrate win_pg12 to debian pg14.
> But there is a new problem, which was not there at the initial stage so I
> checked:
>
> win_pg12:
> ->  Index Scan using index_class_tree_full on class c  (cost=0.28..2.50 rows=1
> width=235) (actual time=0.030..0.032 rows=1 loops=1)
>                      Index Cond: (id = 650)
> debian_pg14:  
> ->  Index Scan using index_class_tree_full on class c  (cost=0.28..2.50 rows=1
> width=235) (actual time=842.795..842.796 rows=1 loops=1)
>                      Index Cond: (id = 650)

Is this repeatable or did it just occur once?

32 µs to retrieve a single row via index probably means that it was
already cached in RAM
842796 µs to retrieve a single row via index doesn't even look realistic
for a completely cold database on a slow rotating hard disk. If this
happened only once I suspect that something else interfered (maybe
another I/O intensive process, if this is on a VM maybe even on another
guest). If it is repeatable, something very weird is going on.

        hp

--
   _  | Peter J. Holzer    | Story must make more sense than reality.
|_|_) |                    |
| |   | hjp@hjp.at         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"

Вложения

В списке pgsql-general по дате отправления:

Предыдущее
От: Дмитрий Иванов
Дата:
Сообщение: Re: Difference in execution plans pg12 vs pg14
Следующее
От: Дмитрий Иванов
Дата:
Сообщение: Re: Difference in execution plans pg12 vs pg14