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
|
Список | 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 по дате отправления: