PostgreSQL Antipatterns: создаем JSON из строки

[ptr128]

Если уж выжимать миллисекунды, то так:

EXPLAIN (ANALYZE, COSTS off)
WITH T AS (
  SELECT
    i
  , repeat(' ', i::integer % 256) s
  FROM
    generate_series(1, 1e6) i
)
SELECT
  ('{"i":'||T.i||'}')::json json
FROM T;

[Kilor]

Все равно чуть хуже row_to_json получается (796ms vs 792ms), но много больше вариантов накосячить с экранированием становится.

[ptr128]

У меня наоборот.

row_to_json Execution Time: 427.457 ms
Через строку Execution Time: 387.150 ms

На другом серваке

row_to_json Execution Time: 392.868 ms
Через строку Execution Time: 366.481 ms

[Kilor]

Возможно, от версии PG или даже ОС зависит - у меня даже просто получение строки '{"i" : ' || i || '}' без каста занимает примерно 570ms из 800ms.

[ptr128]

Ну так у Вас и строка на два байта длинней, чем у меня или у row_to_json.

[ptr128]

Если Вы не скопировали мой код, а сделали свой с лишними двумя пробелами, то запись и чтение этих дополнительных двух мегабайт и съела всё преимущество по времени выполнения, которое вижу я.

[Kilor]

У меня что с пробелами, что без - одно и тоже время с разбежкой в пределах погрешности.

[ptr128]

Я на двух разных серверах проверял. Так что счет 2:1 в мою пользу )

А вообще странно, так как подобные операции выполняются полностью в оперативке и от ОС явно не зависят.

Ради интереса проверил ещё на 12 версии PostgreSQL, там чуть медленней, чем на 15 и 17, но в процентном отношении различие сохраняется.

[pankraty]

А потом в реальной жизни внезапно потребуется, помимо числовых значений, в JSON положить текстовые, потом там встретится кавычка, которую забыли экранировать, и привет...

[ptr128]

Я не спорю, что '[{"i" : 1}, {"i" : "bla"}, {"i" : "5.5"}]' корректный JSON. Но намеренно запихивать такое в РСУБД - это уже и в какие ворота не лезет.

[breninsul]

ну, это же шутка, я надеюсь, никто же не станет писать такое в проде