PostgreSQL ਐਂਟੀਪੈਟਰਨ: ਆਉ ਇੱਕ ਸ਼ਬਦਕੋਸ਼ ਦੇ ਨਾਲ ਭਾਰੀ ਜੁਆਇਨ ਕਰੀਏ

ਅਸੀਂ "ਪ੍ਰਤੀਤ ਤੌਰ 'ਤੇ ਸਧਾਰਨ" PostgreSQL ਸਵਾਲਾਂ ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਲਈ ਬਹੁਤ ਘੱਟ ਜਾਣੇ-ਪਛਾਣੇ ਤਰੀਕਿਆਂ ਦੇ ਅਧਿਐਨ ਲਈ ਸਮਰਪਿਤ ਲੇਖਾਂ ਦੀ ਲੜੀ ਨੂੰ ਜਾਰੀ ਰੱਖਦੇ ਹਾਂ:

• ਦੁਰਲੱਭ ਰਿਕਾਰਡ JOIN ਦੇ ਮੱਧ ਤੱਕ ਪਹੁੰਚ ਜਾਵੇਗਾ
• Sisyphean JOIN ਐਰੇ
• ਹਾਨੀਕਾਰਕ JOIN ਅਤੇ OR
• CTE CTE ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਵੋ

ਇਹ ਨਾ ਸੋਚੋ ਕਿ ਮੈਨੂੰ ਸ਼ਾਮਲ ਹੋਣਾ ਬਹੁਤ ਪਸੰਦ ਨਹੀਂ ਹੈ... :)

ਪਰ ਅਕਸਰ ਇਸਦੇ ਬਿਨਾਂ, ਬੇਨਤੀ ਇਸਦੇ ਨਾਲ ਨਾਲੋਂ ਕਾਫ਼ੀ ਜ਼ਿਆਦਾ ਲਾਭਕਾਰੀ ਸਾਬਤ ਹੁੰਦੀ ਹੈ. ਇਸ ਲਈ ਅੱਜ ਅਸੀਂ ਕੋਸ਼ਿਸ਼ ਕਰਾਂਗੇ ਸਰੋਤ-ਸੰਬੰਧੀ ਸ਼ਾਮਲ ਹੋਣ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾਓ - ਇੱਕ ਸ਼ਬਦਕੋਸ਼ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ.

PostgreSQL 12 ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋਏ, ਹੇਠਾਂ ਦੱਸੀਆਂ ਗਈਆਂ ਕੁਝ ਸਥਿਤੀਆਂ ਦੇ ਕਾਰਨ ਥੋੜ੍ਹੇ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਦੁਬਾਰਾ ਤਿਆਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਡਿਫਾਲਟ ਗੈਰ-ਪਦਾਰਥੀਕਰਨ CTE. ਇਸ ਵਿਵਹਾਰ ਨੂੰ ਕੁੰਜੀ ਦੇ ਕੇ ਵਾਪਸ ਲਿਆ ਜਾ ਸਕਦਾ ਹੈ MATERIALIZED.

ਇੱਕ ਸੀਮਤ ਸ਼ਬਦਾਵਲੀ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ "ਤੱਥ"

ਚਲੋ ਇੱਕ ਬਹੁਤ ਹੀ ਅਸਲ ਐਪਲੀਕੇਸ਼ਨ ਟਾਸਕ ਲੈਂਦੇ ਹਾਂ - ਸਾਨੂੰ ਇੱਕ ਸੂਚੀ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਆਉਣ ਵਾਲੇ ਸੁਨੇਹੇ ਜਾਂ ਭੇਜਣ ਵਾਲਿਆਂ ਨਾਲ ਸਰਗਰਮ ਕੰਮ:

25.01 | Иванов И.И. | Подготовить описание нового алгоритма.
22.01 | Иванов И.И. | Написать статью на Хабр: жизнь без JOIN.
20.01 | Петров П.П. | Помочь оптимизировать запрос.
18.01 | Иванов И.И. | Написать статью на Хабр: JOIN с учетом распределения данных.
16.01 | Петров П.П. | Помочь оптимизировать запрос.

ਸੰਖੇਪ ਸੰਸਾਰ ਵਿੱਚ, ਕਾਰਜ ਲੇਖਕਾਂ ਨੂੰ ਸਾਡੀ ਸੰਸਥਾ ਦੇ ਸਾਰੇ ਕਰਮਚਾਰੀਆਂ ਵਿੱਚ ਬਰਾਬਰ ਵੰਡਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਪਰ ਅਸਲ ਵਿੱਚ ਕੰਮ, ਇੱਕ ਨਿਯਮ ਦੇ ਤੌਰ ਤੇ, ਕਾਫ਼ੀ ਸੀਮਤ ਲੋਕਾਂ ਤੋਂ ਆਉਂਦੇ ਹਨ - "ਪ੍ਰਬੰਧਨ ਤੋਂ" ਦਰਜਾਬੰਦੀ ਤੋਂ ਉੱਪਰ ਜਾਂ ਗੁਆਂਢੀ ਵਿਭਾਗਾਂ (ਵਿਸ਼ਲੇਸ਼ਕ, ਡਿਜ਼ਾਈਨਰ, ਮਾਰਕੀਟਿੰਗ, ...) ਤੋਂ "ਉਪ-ਠੇਕੇਦਾਰਾਂ ਤੋਂ"।

ਆਓ ਸਵੀਕਾਰ ਕਰੀਏ ਕਿ 1000 ਲੋਕਾਂ ਦੀ ਸਾਡੀ ਸੰਸਥਾ ਵਿੱਚ, ਸਿਰਫ 20 ਲੇਖਕ (ਆਮ ਤੌਰ 'ਤੇ ਇਸ ਤੋਂ ਵੀ ਘੱਟ) ਹਰੇਕ ਖਾਸ ਕਲਾਕਾਰ ਲਈ ਕੰਮ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ ਅਤੇ ਆਓ ਇਸ ਵਿਸ਼ੇ ਦੇ ਗਿਆਨ ਦੀ ਵਰਤੋਂ ਕਰੀਏ"ਰਵਾਇਤੀ" ਪੁੱਛਗਿੱਛ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਲਈ।

ਸਕ੍ਰਿਪਟ ਜਨਰੇਟਰ

-- сотрудники
CREATE TABLE person AS
SELECT
  id
, repeat(chr(ascii('a') + (id % 26)), (id % 32) + 1) "name"
, '2000-01-01'::date - (random() * 1e4)::integer birth_date
FROM
  generate_series(1, 1000) id;

ALTER TABLE person ADD PRIMARY KEY(id);

-- задачи с указанным распределением
CREATE TABLE task AS
WITH aid AS (
  SELECT
    id
  , array_agg((random() * 999)::integer + 1) aids
  FROM
    generate_series(1, 1000) id
  , generate_series(1, 20)
  GROUP BY
    1
)
SELECT
  *
FROM
  (
    SELECT
      id
    , '2020-01-01'::date - (random() * 1e3)::integer task_date
    , (random() * 999)::integer + 1 owner_id
    FROM
      generate_series(1, 100000) id
  ) T
, LATERAL(
    SELECT
      aids[(random() * (array_length(aids, 1) - 1))::integer + 1] author_id
    FROM
      aid
    WHERE
      id = T.owner_id
    LIMIT 1
  ) a;

ALTER TABLE task ADD PRIMARY KEY(id);
CREATE INDEX ON task(owner_id, task_date);
CREATE INDEX ON task(author_id);

ਆਉ ਇੱਕ ਖਾਸ ਐਗਜ਼ੀਕਿਊਟਰ ਲਈ ਆਖਰੀ 100 ਕਾਰਜ ਦਿਖਾਉਂਦੇ ਹਾਂ:

SELECT
  task.*
, person.name
FROM
  task
LEFT JOIN
  person
    ON person.id = task.author_id
WHERE
  owner_id = 777
ORDER BY
  task_date DESC
LIMIT 100;

[explanation.tensor.ru 'ਤੇ ਦੇਖੋ]

ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ 1/3 ਕੁੱਲ ਸਮਾਂ ਅਤੇ 3/4 ਰੀਡਿੰਗ ਡੇਟਾ ਦੇ ਪੰਨਿਆਂ ਨੂੰ ਲੇਖਕ ਦੀ ਖੋਜ ਕਰਨ ਲਈ 100 ਵਾਰ ਬਣਾਇਆ ਗਿਆ ਸੀ - ਹਰੇਕ ਆਉਟਪੁੱਟ ਕਾਰਜ ਲਈ। ਪਰ ਅਸੀਂ ਜਾਣਦੇ ਹਾਂ ਕਿ ਇਹਨਾਂ ਸੈਂਕੜੇ ਵਿੱਚੋਂ ਸਿਰਫ 20 ਵੱਖਰੇ - ਕੀ ਇਸ ਗਿਆਨ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸੰਭਵ ਹੈ?

hstore-ਕੋਸ਼

ਆਓ ਲਾਭ ਉਠਾਈਏ hstore ਕਿਸਮ ਇੱਕ "ਡਕਸ਼ਨਰੀ" ਕੁੰਜੀ-ਮੁੱਲ ਬਣਾਉਣ ਲਈ:

CREATE EXTENSION hstore

ਸਾਨੂੰ ਲੇਖਕ ਦੀ ID ਅਤੇ ਉਸਦਾ ਨਾਮ ਸ਼ਬਦਕੋਸ਼ ਵਿੱਚ ਪਾਉਣ ਦੀ ਲੋੜ ਹੈ ਤਾਂ ਜੋ ਅਸੀਂ ਫਿਰ ਇਸ ਕੁੰਜੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਐਕਸਟਰੈਕਟ ਕਰ ਸਕੀਏ:

-- формируем целевую выборку
WITH T AS (
  SELECT
    *
  FROM
    task
  WHERE
    owner_id = 777
  ORDER BY
    task_date DESC
  LIMIT 100
)
-- формируем словарь для уникальных значений
, dict AS (
  SELECT
    hstore( -- hstore(keys::text[], values::text[])
      array_agg(id)::text[]
    , array_agg(name)::text[]
    )
  FROM
    person
  WHERE
    id = ANY(ARRAY(
      SELECT DISTINCT
        author_id
      FROM
        T
    ))
)
-- получаем связанные значения словаря
SELECT
  *
, (TABLE dict) -> author_id::text -- hstore -> key
FROM
  T;

[explanation.tensor.ru 'ਤੇ ਦੇਖੋ]

ਵਿਅਕਤੀਆਂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰਨ 'ਤੇ ਖਰਚ ਕੀਤਾ ਗਿਆ 2 ਗੁਣਾ ਘੱਟ ਸਮਾਂ ਅਤੇ 7 ਗੁਣਾ ਘੱਟ ਡਾਟਾ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ! "ਸ਼ਬਦਾਵਲੀ" ਤੋਂ ਇਲਾਵਾ, ਇਹਨਾਂ ਨਤੀਜਿਆਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਵਿੱਚ ਸਾਡੀ ਮਦਦ ਕੀਤੀ ਬਲਕ ਰਿਕਾਰਡ ਮੁੜ ਪ੍ਰਾਪਤੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਇੱਕ ਸਿੰਗਲ ਪਾਸ ਵਿੱਚ ਟੇਬਲ ਤੋਂ = ANY(ARRAY(...)).

ਟੇਬਲ ਐਂਟਰੀਆਂ: ਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ ਅਤੇ ਡੀਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ

ਪਰ ਉਦੋਂ ਕੀ ਜੇ ਸਾਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਟੈਕਸਟ ਖੇਤਰ ਨੂੰ ਹੀ ਨਹੀਂ, ਸਗੋਂ ਸ਼ਬਦਕੋਸ਼ ਵਿੱਚ ਇੱਕ ਪੂਰੀ ਐਂਟਰੀ ਨੂੰ ਬਚਾਉਣ ਦੀ ਲੋੜ ਹੈ? ਇਸ ਸਥਿਤੀ ਵਿੱਚ, PostgreSQL ਦੀ ਯੋਗਤਾ ਸਾਡੀ ਮਦਦ ਕਰੇਗੀ ਇੱਕ ਟੇਬਲ ਐਂਟਰੀ ਨੂੰ ਇੱਕ ਇੱਕਲੇ ਮੁੱਲ ਵਜੋਂ ਮੰਨੋ:

...
, dict AS (
  SELECT
    hstore(
      array_agg(id)::text[]
    , array_agg(p)::text[] -- магия #1
    )
  FROM
    person p
  WHERE
    ...
)
SELECT
  *
, (((TABLE dict) -> author_id::text)::person).* -- магия #2
FROM
  T;

ਆਓ ਦੇਖੀਏ ਕਿ ਇੱਥੇ ਕੀ ਹੋ ਰਿਹਾ ਸੀ:

1. ਅਸੀਂ ਲਿਆ p ਪੂਰੇ ਵਿਅਕਤੀ ਟੇਬਲ ਐਂਟਰੀ ਲਈ ਉਪਨਾਮ ਵਜੋਂ ਅਤੇ ਉਹਨਾਂ ਦੀ ਇੱਕ ਲੜੀ ਨੂੰ ਇਕੱਠਾ ਕੀਤਾ।
2. ਇਸ ਰਿਕਾਰਡਿੰਗਾਂ ਦੀ ਲੜੀ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਇਆ ਗਿਆ ਸੀ ਇਸ ਨੂੰ hstore ਡਿਕਸ਼ਨਰੀ ਵਿੱਚ ਮੁੱਲਾਂ ਦੀ ਇੱਕ ਐਰੇ ਵਜੋਂ ਰੱਖਣ ਲਈ ਟੈਕਸਟ ਸਤਰਾਂ ਦੀ ਇੱਕ ਐਰੇ (person[]::text[]) ਵਿੱਚ।
3. ਜਦੋਂ ਅਸੀਂ ਇੱਕ ਸੰਬੰਧਿਤ ਰਿਕਾਰਡ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ, ਅਸੀਂ ਕੁੰਜੀ ਦੁਆਰਾ ਸ਼ਬਦਕੋਸ਼ ਵਿੱਚੋਂ ਖਿੱਚਿਆ ਗਿਆ ਇੱਕ ਟੈਕਸਟ ਸਤਰ ਦੇ ਰੂਪ ਵਿੱਚ.
4. ਸਾਨੂੰ ਟੈਕਸਟ ਦੀ ਲੋੜ ਹੈ ਇੱਕ ਸਾਰਣੀ ਕਿਸਮ ਦੇ ਮੁੱਲ ਵਿੱਚ ਬਦਲੋ ਵਿਅਕਤੀ (ਹਰੇਕ ਟੇਬਲ ਲਈ ਇੱਕੋ ਨਾਮ ਦੀ ਇੱਕ ਕਿਸਮ ਆਪਣੇ ਆਪ ਬਣ ਜਾਂਦੀ ਹੈ)।
5. ਟਾਈਪ ਕੀਤੇ ਰਿਕਾਰਡ ਨੂੰ ਕਾਲਮਾਂ ਵਿੱਚ ਵਰਤਦੇ ਹੋਏ "ਵਿਸਤਾਰ ਕਰੋ" (...).*.

json ਸ਼ਬਦਕੋਸ਼

ਪਰ ਅਜਿਹੀ ਚਾਲ ਜਿਵੇਂ ਅਸੀਂ ਉੱਪਰ ਲਾਗੂ ਕੀਤੀ ਹੈ ਕੰਮ ਨਹੀਂ ਕਰੇਗੀ ਜੇਕਰ "ਕਾਸਟਿੰਗ" ਕਰਨ ਲਈ ਕੋਈ ਅਨੁਸਾਰੀ ਟੇਬਲ ਕਿਸਮ ਨਹੀਂ ਹੈ। ਬਿਲਕੁਲ ਉਹੀ ਸਥਿਤੀ ਪੈਦਾ ਹੋਵੇਗੀ, ਅਤੇ ਜੇ ਅਸੀਂ ਵਰਤਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ ਇੱਕ CTE ਕਤਾਰ, ਇੱਕ "ਅਸਲ" ਸਾਰਣੀ ਨਹੀਂ.

ਇਸ ਮਾਮਲੇ ਵਿੱਚ ਉਹ ਸਾਡੀ ਮਦਦ ਕਰਨਗੇ json ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਫੰਕਸ਼ਨ:

...
, p AS ( -- это уже CTE
  SELECT
    *
  FROM
    person
  WHERE
    ...
)
, dict AS (
  SELECT
    json_object( -- теперь это уже json
      array_agg(id)::text[]
    , array_agg(row_to_json(p))::text[] -- и внутри json для каждой строки
    )
  FROM
    p
)
SELECT
  *
FROM
  T
, LATERAL(
    SELECT
      *
    FROM
      json_to_record(
        ((TABLE dict) ->> author_id::text)::json -- извлекли из словаря как json
      ) AS j(name text, birth_date date) -- заполнили нужную нам структуру
  ) j;

ਇਹ ਨੋਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਟੀਚੇ ਦੀ ਬਣਤਰ ਦਾ ਵਰਣਨ ਕਰਦੇ ਸਮੇਂ, ਅਸੀਂ ਸਰੋਤ ਸਤਰ ਦੇ ਸਾਰੇ ਖੇਤਰਾਂ ਨੂੰ ਸੂਚੀਬੱਧ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਪਰ ਸਿਰਫ ਉਹਨਾਂ ਦੀ ਹੀ ਲੋੜ ਹੈ ਜੋ ਸਾਨੂੰ ਅਸਲ ਵਿੱਚ ਲੋੜੀਂਦੇ ਹਨ। ਜੇ ਸਾਡੇ ਕੋਲ "ਦੇਸੀ" ਟੇਬਲ ਹੈ, ਤਾਂ ਫੰਕਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਬਿਹਤਰ ਹੈ json_populate_record.

ਅਸੀਂ ਅਜੇ ਵੀ ਇੱਕ ਵਾਰ ਡਿਕਸ਼ਨਰੀ ਤੱਕ ਪਹੁੰਚ ਕਰਦੇ ਹਾਂ, ਪਰ json-[de] ਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ ਲਾਗਤਾਂ ਕਾਫ਼ੀ ਜ਼ਿਆਦਾ ਹਨ, ਇਸਲਈ, ਇਸ ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕੇਵਲ ਕੁਝ ਮਾਮਲਿਆਂ ਵਿੱਚ ਹੀ ਉਚਿਤ ਹੈ ਜਦੋਂ "ਇਮਾਨਦਾਰ" CTE ਸਕੈਨ ਆਪਣੇ ਆਪ ਨੂੰ ਹੋਰ ਬਦਤਰ ਦਿਖਾਉਂਦਾ ਹੈ।

ਟੈਸਟਿੰਗ ਪ੍ਰਦਰਸ਼ਨ

ਇਸ ਲਈ, ਸਾਨੂੰ ਇੱਕ ਸ਼ਬਦਕੋਸ਼ ਵਿੱਚ ਡੇਟਾ ਨੂੰ ਲੜੀਬੱਧ ਕਰਨ ਦੇ ਦੋ ਤਰੀਕੇ ਮਿਲੇ ਹਨ - hstore/json_object. ਇਸ ਤੋਂ ਇਲਾਵਾ, ਕੁੰਜੀਆਂ ਅਤੇ ਮੁੱਲਾਂ ਦੇ ਐਰੇ ਵੀ ਦੋ ਤਰੀਕਿਆਂ ਨਾਲ ਤਿਆਰ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ, ਟੈਕਸਟ ਵਿੱਚ ਅੰਦਰੂਨੀ ਜਾਂ ਬਾਹਰੀ ਰੂਪਾਂਤਰਨ ਦੇ ਨਾਲ: array_agg(i::text) / array_agg(i)::text[].

ਆਉ ਇੱਕ ਸ਼ੁੱਧ ਸਿੰਥੈਟਿਕ ਉਦਾਹਰਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਵੱਖ-ਵੱਖ ਕਿਸਮਾਂ ਦੇ ਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ ਦੀ ਪ੍ਰਭਾਵਸ਼ੀਲਤਾ ਦੀ ਜਾਂਚ ਕਰੀਏ - ਕੁੰਜੀਆਂ ਦੇ ਵੱਖ-ਵੱਖ ਨੰਬਰਾਂ ਨੂੰ ਸੀਰੀਅਲਾਈਜ਼ ਕਰੋ:

WITH dict AS (
  SELECT
    hstore(
      array_agg(i::text)
    , array_agg(i::text)
    )
  FROM
    generate_series(1, ...) i
)
TABLE dict;

ਮੁਲਾਂਕਣ ਸਕ੍ਰਿਪਟ: ਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ

WITH T AS (
  SELECT
    *
  , (
      SELECT
        regexp_replace(ea[array_length(ea, 1)], '^Execution Time: (d+.d+) ms$', '1')::real et
      FROM
        (
          SELECT
            array_agg(el) ea
          FROM
            dblink('port= ' || current_setting('port') || ' dbname=' || current_database(), $$
              explain analyze
              WITH dict AS (
                SELECT
                  hstore(
                    array_agg(i::text)
                  , array_agg(i::text)
                  )
                FROM
                  generate_series(1, $$ || (1 << v) || $$) i
              )
              TABLE dict
            $$) T(el text)
        ) T
    ) et
  FROM
    generate_series(0, 19) v
  ,   LATERAL generate_series(1, 7) i
  ORDER BY
    1, 2
)
SELECT
  v
, avg(et)::numeric(32,3)
FROM
  T
GROUP BY
  1
ORDER BY
  1;

PostgreSQL 11 'ਤੇ, ਲਗਭਗ 2^12 ਕੁੰਜੀਆਂ ਦੇ ਸ਼ਬਦਕੋਸ਼ ਆਕਾਰ ਤੱਕ ਜੇਸਨ ਨੂੰ ਸੀਰੀਅਲਾਈਜ਼ ਕਰਨ ਵਿੱਚ ਘੱਟ ਸਮਾਂ ਲੱਗਦਾ ਹੈ. ਇਸ ਕੇਸ ਵਿੱਚ, ਸਭ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ json_object ਅਤੇ "ਅੰਦਰੂਨੀ" ਕਿਸਮ ਦੇ ਰੂਪਾਂਤਰਣ ਦਾ ਸੁਮੇਲ ਹੈ। array_agg(i::text).

ਹੁਣ ਹਰ ਕੁੰਜੀ ਦੇ ਮੁੱਲ ਨੂੰ 8 ਵਾਰ ਪੜ੍ਹਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ - ਆਖਰਕਾਰ, ਜੇਕਰ ਤੁਸੀਂ ਸ਼ਬਦਕੋਸ਼ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦੇ ਹੋ, ਤਾਂ ਇਸਦੀ ਲੋੜ ਕਿਉਂ ਹੈ?

ਮੁਲਾਂਕਣ ਸਕ੍ਰਿਪਟ: ਡਿਕਸ਼ਨਰੀ ਤੋਂ ਪੜ੍ਹਨਾ

WITH T AS (
  SELECT
    *
  , (
      SELECT
        regexp_replace(ea[array_length(ea, 1)], '^Execution Time: (d+.d+) ms$', '1')::real et
      FROM
        (
          SELECT
            array_agg(el) ea
          FROM
            dblink('port= ' || current_setting('port') || ' dbname=' || current_database(), $$
              explain analyze
              WITH dict AS (
                SELECT
                  json_object(
                    array_agg(i::text)
                  , array_agg(i::text)
                  )
                FROM
                  generate_series(1, $$ || (1 << v) || $$) i
              )
              SELECT
                (TABLE dict) -> (i % ($$ || (1 << v) || $$) + 1)::text
              FROM
                generate_series(1, $$ || (1 << (v + 3)) || $$) i
            $$) T(el text)
        ) T
    ) et
  FROM
    generate_series(0, 19) v
  , LATERAL generate_series(1, 7) i
  ORDER BY
    1, 2
)
SELECT
  v
, avg(et)::numeric(32,3)
FROM
  T
GROUP BY
  1
ORDER BY
  1;

ਅਤੇ... ਪਹਿਲਾਂ ਹੀ ਲਗਭਗ 2^6 ਕੁੰਜੀਆਂ ਨਾਲ, ਜੇਸਨ ਡਿਕਸ਼ਨਰੀ ਤੋਂ ਪੜ੍ਹਨਾ ਕਈ ਵਾਰ ਗੁਆਉਣਾ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦਾ ਹੈ hstore ਤੋਂ ਪੜ੍ਹਨਾ, jsonb ਲਈ ਇਹੀ 2^9 'ਤੇ ਹੁੰਦਾ ਹੈ।

ਅੰਤਮ ਸਿੱਟੇ:

• ਜੇਕਰ ਤੁਹਾਨੂੰ ਇਹ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਕਈ ਦੁਹਰਾਉਣ ਵਾਲੇ ਰਿਕਾਰਡਾਂ ਨਾਲ ਜੁੜੋ - ਸਾਰਣੀ ਦੀ "ਡਕਸ਼ਨਰੀ" ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਬਿਹਤਰ ਹੈ
• ਜੇਕਰ ਤੁਹਾਡੇ ਸ਼ਬਦਕੋਸ਼ ਦੀ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਛੋਟਾ ਹੈ ਅਤੇ ਤੁਸੀਂ ਇਸ ਤੋਂ ਜ਼ਿਆਦਾ ਨਹੀਂ ਪੜ੍ਹੋਗੇ - ਤੁਸੀਂ json [b] ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ
• ਹੋਰ ਸਾਰੇ ਮਾਮਲਿਆਂ ਵਿੱਚ hstore + array_agg(i::text) ਵਧੇਰੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੋਵੇਗਾ

ਸਰੋਤ: www.habr.com