Re: remaining sql/json patches
От | John Naylor |
---|---|
Тема | Re: remaining sql/json patches |
Дата | |
Msg-id | CANWCAZaF0a+GCqJN+DP5FwNpDiVt4758Fi-UWn98FunMLaw1EQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: remaining sql/json patches (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: remaining sql/json patches
|
Список | pgsql-hackers |
On Mon, Nov 27, 2023 at 8:57 PM Andrew Dunstan <andrew@dunslane.net> wrote: > Interesting. But inferring a speed effect from such changes is > difficult. I don't have a good idea about measuring parser speed, but a > tool to do that would be useful. Amit has made a start on such > measurements, but it's only a start. I'd prefer to have evidence rather > than speculation. Tom shared this test a while back, and that's the one I've used in the past. The downside for a micro-benchmark like that is that it can monopolize the CPU cache. Cache misses in real world queries are likely much more dominant. https://www.postgresql.org/message-id/14616.1558560331@sss.pgh.pa.us Aside on the relevance of parser speed: I've seen customers successfully lower their monthly cloud bills by moving away from prepared statements, allowing smaller-memory instances.
В списке pgsql-hackers по дате отправления: