PostgreSQL ਪੁੱਛਗਿੱਛ ਪ੍ਰੋਫਾਈਲਰ: ਯੋਜਨਾ ਅਤੇ ਪੁੱਛਗਿੱਛ ਦਾ ਮੇਲ ਕਿਵੇਂ ਕਰੀਏ

ਬਹੁਤ ਸਾਰੇ ਜੋ ਪਹਿਲਾਂ ਹੀ ਵਰਤ ਰਹੇ ਹਨ explain.tensor.ru - ਸਾਡੀ PostgreSQL ਯੋਜਨਾ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਸੇਵਾ ਸ਼ਾਇਦ ਇਸਦੀ ਕਿਸੇ ਇੱਕ ਮਹਾਂਸ਼ਕਤੀ ਤੋਂ ਜਾਣੂ ਨਾ ਹੋਵੇ - ਸਰਵਰ ਲੌਗ ਦੇ ਇੱਕ ਪੜ੍ਹਨ ਲਈ ਔਖੇ ਹਿੱਸੇ ਨੂੰ ਮੋੜਨਾ...

... ਅਨੁਸਾਰੀ ਯੋਜਨਾ ਨੋਡਾਂ ਲਈ ਪ੍ਰਸੰਗਿਕ ਸੰਕੇਤਾਂ ਦੇ ਨਾਲ ਇੱਕ ਸੁੰਦਰ ਢੰਗ ਨਾਲ ਡਿਜ਼ਾਈਨ ਕੀਤੀ ਪੁੱਛਗਿੱਛ ਵਿੱਚ:

ਉਸਦੇ ਦੂਜੇ ਭਾਗ ਦੇ ਇਸ ਪ੍ਰਤੀਲਿਪੀ ਵਿੱਚ PGConf.Russia 2020 'ਤੇ ਰਿਪੋਰਟ ਮੈਂ ਤੁਹਾਨੂੰ ਦੱਸਾਂਗਾ ਕਿ ਅਸੀਂ ਇਹ ਕਿਵੇਂ ਕਰਨ ਵਿੱਚ ਕਾਮਯਾਬ ਹੋਏ।

ਪਹਿਲੇ ਭਾਗ ਦੀ ਪ੍ਰਤੀਲਿਪੀ, ਖਾਸ ਪੁੱਛਗਿੱਛ ਪ੍ਰਦਰਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਅਤੇ ਉਹਨਾਂ ਦੇ ਹੱਲਾਂ ਨੂੰ ਸਮਰਪਿਤ, ਲੇਖ ਵਿੱਚ ਲੱਭੀ ਜਾ ਸਕਦੀ ਹੈ "ਬੀਮਾਰ SQL ਸਵਾਲਾਂ ਲਈ ਪਕਵਾਨਾ".

ਪਹਿਲਾਂ, ਆਓ ਰੰਗ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰੀਏ - ਅਤੇ ਅਸੀਂ ਹੁਣ ਯੋਜਨਾ ਨੂੰ ਰੰਗ ਨਹੀਂ ਦੇਵਾਂਗੇ, ਅਸੀਂ ਇਸਨੂੰ ਪਹਿਲਾਂ ਹੀ ਰੰਗ ਦਿੱਤਾ ਹੈ, ਸਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਇਹ ਸੁੰਦਰ ਅਤੇ ਸਮਝਣ ਯੋਗ ਹੈ, ਪਰ ਇੱਕ ਬੇਨਤੀ.

ਇਹ ਸਾਨੂੰ ਜਾਪਦਾ ਸੀ ਕਿ ਅਜਿਹੀ ਗੈਰ-ਫਾਰਮੈਟਡ "ਸ਼ੀਟ" ਨਾਲ ਲੌਗ ਤੋਂ ਖਿੱਚੀ ਗਈ ਬੇਨਤੀ ਬਹੁਤ ਬਦਸੂਰਤ ਅਤੇ ਇਸਲਈ ਅਸੁਵਿਧਾਜਨਕ ਲੱਗਦੀ ਹੈ।


ਖ਼ਾਸਕਰ ਜਦੋਂ ਡਿਵੈਲਪਰ ਕੋਡ ਵਿੱਚ ਬੇਨਤੀ ਦੇ ਸਰੀਰ ਨੂੰ "ਗੂੰਦ" ਕਰਦੇ ਹਨ (ਇਹ, ਬੇਸ਼ਕ, ਇੱਕ ਐਂਟੀਪੈਟਰਨ ਹੈ, ਪਰ ਅਜਿਹਾ ਹੁੰਦਾ ਹੈ) ਇੱਕ ਲਾਈਨ ਵਿੱਚ. ਭਿਆਨਕ!

ਚਲੋ ਇਸ ਨੂੰ ਹੋਰ ਵੀ ਖੂਬਸੂਰਤੀ ਨਾਲ ਖਿੱਚੀਏ।


ਅਤੇ ਜੇ ਅਸੀਂ ਇਸ ਨੂੰ ਸੁੰਦਰਤਾ ਨਾਲ ਖਿੱਚ ਸਕਦੇ ਹਾਂ, ਭਾਵ, ਬੇਨਤੀ ਦੇ ਮੁੱਖ ਹਿੱਸੇ ਨੂੰ ਵੱਖ ਕਰ ਸਕਦੇ ਹਾਂ ਅਤੇ ਵਾਪਸ ਜੋੜ ਸਕਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਫਿਰ ਇਸ ਬੇਨਤੀ ਦੇ ਹਰੇਕ ਆਬਜੈਕਟ ਲਈ ਇੱਕ ਸੰਕੇਤ "ਨੱਥੀ" ਕਰ ਸਕਦੇ ਹਾਂ - ਯੋਜਨਾ ਦੇ ਅਨੁਸਾਰੀ ਬਿੰਦੂ 'ਤੇ ਕੀ ਹੋਇਆ।

ਸਵਾਲ ਸੰਟੈਕਸ ਟ੍ਰੀ

ਅਜਿਹਾ ਕਰਨ ਲਈ, ਬੇਨਤੀ ਨੂੰ ਪਹਿਲਾਂ ਪਾਰਸ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।


ਕਿਉਂਕਿ ਸਾਡੇ ਕੋਲ ਹੈ ਸਿਸਟਮ ਦਾ ਕੋਰ NodeJS 'ਤੇ ਚੱਲਦਾ ਹੈ, ਫਿਰ ਅਸੀਂ ਇਸਦੇ ਲਈ ਇੱਕ ਮੋਡੀਊਲ ਬਣਾਇਆ ਹੈ, ਤੁਸੀਂ ਕਰ ਸਕਦੇ ਹੋ ਇਸਨੂੰ GitHub 'ਤੇ ਲੱਭੋ. ਵਾਸਤਵ ਵਿੱਚ, ਇਹ PostgreSQL ਪਾਰਸਰ ਦੇ ਅੰਦਰੂਨੀ ਹਿੱਸੇ ਵਿੱਚ "ਬਾਈਡਿੰਗ" ਨੂੰ ਵਧਾਇਆ ਗਿਆ ਹੈ. ਭਾਵ, ਵਿਆਕਰਣ ਨੂੰ ਸਿਰਫ਼ ਬਾਈਨਰੀ ਕੰਪਾਇਲ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਨੋਡਜੇਐਸ ਤੋਂ ਬਾਈਡਿੰਗ ਬਣਾਏ ਗਏ ਹਨ। ਅਸੀਂ ਦੂਜੇ ਲੋਕਾਂ ਦੇ ਮੋਡਿਊਲ ਨੂੰ ਆਧਾਰ ਵਜੋਂ ਲਿਆ - ਇੱਥੇ ਕੋਈ ਵੱਡਾ ਰਾਜ਼ ਨਹੀਂ ਹੈ.

ਅਸੀਂ ਬੇਨਤੀ ਦੇ ਮੁੱਖ ਭਾਗ ਨੂੰ ਸਾਡੇ ਫੰਕਸ਼ਨ ਲਈ ਇਨਪੁਟ ਵਜੋਂ ਫੀਡ ਕਰਦੇ ਹਾਂ - ਆਉਟਪੁੱਟ 'ਤੇ ਸਾਨੂੰ JSON ਵਸਤੂ ਦੇ ਰੂਪ ਵਿੱਚ ਇੱਕ ਪਾਰਸਡ ਸਿੰਟੈਕਸ ਟ੍ਰੀ ਮਿਲਦਾ ਹੈ।


ਹੁਣ ਅਸੀਂ ਇਸ ਟ੍ਰੀ ਨੂੰ ਉਲਟ ਦਿਸ਼ਾ ਵਿੱਚ ਚਲਾ ਸਕਦੇ ਹਾਂ ਅਤੇ ਇੰਡੈਂਟਸ, ਕਲਰਿੰਗ, ਅਤੇ ਫਾਰਮੈਟਿੰਗ ਦੇ ਨਾਲ ਇੱਕ ਬੇਨਤੀ ਇਕੱਠੀ ਕਰ ਸਕਦੇ ਹਾਂ ਜੋ ਅਸੀਂ ਚਾਹੁੰਦੇ ਹਾਂ। ਨਹੀਂ, ਇਹ ਅਨੁਕੂਲਿਤ ਨਹੀਂ ਹੈ, ਪਰ ਇਹ ਸਾਨੂੰ ਲੱਗਦਾ ਸੀ ਕਿ ਇਹ ਸੁਵਿਧਾਜਨਕ ਹੋਵੇਗਾ।

ਮੈਪਿੰਗ ਪੁੱਛਗਿੱਛ ਅਤੇ ਯੋਜਨਾ ਨੋਡ

ਹੁਣ ਆਓ ਦੇਖੀਏ ਕਿ ਅਸੀਂ ਉਸ ਯੋਜਨਾ ਨੂੰ ਕਿਵੇਂ ਜੋੜ ਸਕਦੇ ਹਾਂ ਜਿਸਦਾ ਅਸੀਂ ਪਹਿਲੇ ਪੜਾਅ ਵਿੱਚ ਵਿਸ਼ਲੇਸ਼ਣ ਕੀਤਾ ਸੀ ਅਤੇ ਉਸ ਸਵਾਲ ਦਾ ਜਿਸਦਾ ਅਸੀਂ ਦੂਜੇ ਪੜਾਅ ਵਿੱਚ ਵਿਸ਼ਲੇਸ਼ਣ ਕੀਤਾ ਸੀ।

ਆਉ ਇੱਕ ਸਧਾਰਨ ਉਦਾਹਰਨ ਲਈਏ - ਸਾਡੇ ਕੋਲ ਇੱਕ ਪੁੱਛਗਿੱਛ ਹੈ ਜੋ ਇੱਕ CTE ਤਿਆਰ ਕਰਦੀ ਹੈ ਅਤੇ ਇਸ ਤੋਂ ਦੋ ਵਾਰ ਪੜ੍ਹਦੀ ਹੈ। ਉਹ ਅਜਿਹੀ ਯੋਜਨਾ ਬਣਾਉਂਦਾ ਹੈ।

CTE

ਜੇ ਤੁਸੀਂ ਇਸ ਨੂੰ ਧਿਆਨ ਨਾਲ ਦੇਖਦੇ ਹੋ, ਸੰਸਕਰਣ 12 ਤੱਕ (ਜਾਂ ਇਸ ਤੋਂ ਕੀਵਰਡ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋਏ MATERIALIZED) ਗਠਨ CTE ਯੋਜਨਾਕਾਰ ਲਈ ਇੱਕ ਪੂਰਨ ਰੁਕਾਵਟ ਹੈ.


ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਜੇਕਰ ਅਸੀਂ ਬੇਨਤੀ ਵਿੱਚ ਕਿਤੇ ਇੱਕ CTE ਪੀੜ੍ਹੀ ਅਤੇ ਯੋਜਨਾ ਵਿੱਚ ਕਿਤੇ ਇੱਕ ਨੋਡ ਦੇਖਦੇ ਹਾਂ CTE, ਫਿਰ ਇਹ ਨੋਡ ਨਿਸ਼ਚਤ ਤੌਰ 'ਤੇ ਇਕ ਦੂਜੇ ਨਾਲ "ਲੜਦੇ ਹਨ", ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਤੁਰੰਤ ਜੋੜ ਸਕਦੇ ਹਾਂ.

ਇੱਕ ਤਾਰੇ ਨਾਲ ਸਮੱਸਿਆ: CTEs ਨੂੰ ਨੇਸਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਇੱਥੇ ਬਹੁਤ ਮਾੜੇ ਆਲ੍ਹਣੇ ਹਨ, ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ ਇੱਕੋ ਨਾਮ ਦੇ ਵੀ। ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ ਅੰਦਰ ਕਰ ਸਕਦੇ ਹੋ CTE A ਬਣਾਉਣ ਲਈ CTE X, ਅਤੇ ਅੰਦਰ ਉਸੇ ਪੱਧਰ 'ਤੇ CTE B ਇਸ ਨੂੰ ਦੁਬਾਰਾ ਕਰੋ CTE X:

WITH A AS (
  WITH X AS (...)
  SELECT ...
)
, B AS (
  WITH X AS (...)
  SELECT ...
)
...

ਤੁਲਨਾ ਕਰਦੇ ਸਮੇਂ, ਤੁਹਾਨੂੰ ਇਹ ਸਮਝਣਾ ਚਾਹੀਦਾ ਹੈ. ਇਸ ਨੂੰ "ਆਪਣੀਆਂ ਅੱਖਾਂ ਨਾਲ" ਸਮਝਣਾ - ਇੱਥੋਂ ਤੱਕ ਕਿ ਯੋਜਨਾ ਨੂੰ ਵੇਖਣਾ, ਬੇਨਤੀ ਦੇ ਸਰੀਰ ਨੂੰ ਵੀ ਵੇਖਣਾ - ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੈ। ਜੇਕਰ ਤੁਹਾਡੀ CTE ਪੀੜ੍ਹੀ ਗੁੰਝਲਦਾਰ ਹੈ, ਨੇਸਟਡ ਹੈ, ਅਤੇ ਬੇਨਤੀਆਂ ਵੱਡੀਆਂ ਹਨ, ਤਾਂ ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੇਹੋਸ਼ ਹੈ।

ਯੂਨੀਅਨ

ਜੇਕਰ ਸਾਡੇ ਕੋਲ ਪੁੱਛਗਿੱਛ ਵਿੱਚ ਇੱਕ ਕੀਵਰਡ ਹੈ UNION [ALL] (ਦੋ ਨਮੂਨਿਆਂ ਨੂੰ ਜੋੜਨ ਦਾ ਆਪਰੇਟਰ), ਫਿਰ ਯੋਜਨਾ ਵਿੱਚ ਇਹ ਜਾਂ ਤਾਂ ਇੱਕ ਨੋਡ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ Append, ਜਾਂ ਕੁਝ Recursive Union.


ਜੋ "ਉੱਪਰ" ਹੈ UNION - ਇਹ ਸਾਡੇ ਨੋਡ ਦਾ ਪਹਿਲਾ ਉੱਤਰਾਧਿਕਾਰੀ ਹੈ, ਜੋ ਕਿ "ਹੇਠਾਂ" ਹੈ - ਦੂਜਾ। ਦੁਆਰਾ ਜੇ UNION ਸਾਡੇ ਕੋਲ ਇੱਕ ਵਾਰ ਵਿੱਚ ਕਈ ਬਲਾਕ "ਚੁੱਕੇ" ਹਨ, ਫਿਰ Append-ਅਜੇ ਵੀ ਸਿਰਫ ਇੱਕ ਨੋਡ ਹੋਵੇਗਾ, ਪਰ ਇਸ ਵਿੱਚ ਦੋ ਨਹੀਂ, ਪਰ ਬਹੁਤ ਸਾਰੇ ਬੱਚੇ ਹੋਣਗੇ - ਕ੍ਰਮਵਾਰ ਉਹ ਜਾਂਦੇ ਹਨ:

  (...) -- #1
UNION ALL
  (...) -- #2
UNION ALL
  (...) -- #3

Append
  -> ... #1
  -> ... #2
  -> ... #3

ਇੱਕ ਤਾਰੇ ਨਾਲ ਸਮੱਸਿਆ: ਆਵਰਤੀ ਨਮੂਨਾ ਬਣਾਉਣ ਦੇ ਅੰਦਰ (WITH RECURSIVE) ਇੱਕ ਤੋਂ ਵੱਧ ਵੀ ਹੋ ਸਕਦੇ ਹਨ UNION. ਪਰ ਆਖਰੀ ਬਲਾਕ ਤੋਂ ਬਾਅਦ ਸਿਰਫ ਬਹੁਤ ਹੀ ਆਖਰੀ ਬਲਾਕ ਹਮੇਸ਼ਾ ਆਵਰਤੀ ਹੁੰਦਾ ਹੈ UNION. ਉਪਰੋਕਤ ਸਭ ਕੁਝ ਇੱਕ ਹੈ, ਪਰ ਵੱਖਰਾ ਹੈ UNION:

WITH RECURSIVE T AS(
  (...) -- #1
UNION ALL
  (...) -- #2, тут кончается генерация стартового состояния рекурсии
UNION ALL
  (...) -- #3, только этот блок рекурсивный и может содержать обращение к T
)
...

ਤੁਹਾਨੂੰ ਅਜਿਹੀਆਂ ਉਦਾਹਰਣਾਂ ਨੂੰ "ਸਟਿੱਕ ਆਊਟ" ਕਰਨ ਦੇ ਯੋਗ ਹੋਣ ਦੀ ਵੀ ਲੋੜ ਹੈ। ਇਸ ਉਦਾਹਰਣ ਵਿੱਚ ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ UNION-ਸਾਡੀ ਬੇਨਤੀ ਵਿੱਚ 3 ਹਿੱਸੇ ਸਨ। ਇਸ ਅਨੁਸਾਰ, ਇੱਕ UNION ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ Append-ਨੋਡ, ਅਤੇ ਦੂਜੇ ਨੂੰ - Recursive Union.

ਡਾਟਾ ਪੜ੍ਹੋ-ਲਿਖੋ

ਸਭ ਕੁਝ ਰੱਖਿਆ ਗਿਆ ਹੈ, ਹੁਣ ਅਸੀਂ ਜਾਣਦੇ ਹਾਂ ਕਿ ਬੇਨਤੀ ਦਾ ਕਿਹੜਾ ਹਿੱਸਾ ਯੋਜਨਾ ਦੇ ਕਿਹੜੇ ਹਿੱਸੇ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ। ਅਤੇ ਇਹਨਾਂ ਟੁਕੜਿਆਂ ਵਿੱਚ ਅਸੀਂ ਉਹਨਾਂ ਵਸਤੂਆਂ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਅਤੇ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਲੱਭ ਸਕਦੇ ਹਾਂ ਜੋ "ਪੜ੍ਹਨਯੋਗ" ਹਨ।

ਪੁੱਛਗਿੱਛ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਅਸੀਂ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਇਹ ਇੱਕ ਸਾਰਣੀ ਹੈ ਜਾਂ ਇੱਕ CTE, ਪਰ ਉਹਨਾਂ ਨੂੰ ਉਸੇ ਨੋਡ ਦੁਆਰਾ ਮਨੋਨੀਤ ਕੀਤਾ ਗਿਆ ਹੈ RangeVar. ਅਤੇ "ਪੜ੍ਹਨਯੋਗਤਾ" ਦੇ ਰੂਪ ਵਿੱਚ, ਇਹ ਨੋਡਾਂ ਦਾ ਇੱਕ ਕਾਫ਼ੀ ਸੀਮਤ ਸਮੂਹ ਵੀ ਹੈ:

• Seq Scan on [tbl]
• Bitmap Heap Scan on [tbl]
• Index [Only] Scan [Backward] using [idx] on [tbl]
• CTE Scan on [cte]
• Insert/Update/Delete on [tbl]

ਅਸੀਂ ਯੋਜਨਾ ਅਤੇ ਪੁੱਛਗਿੱਛ ਦੀ ਬਣਤਰ ਨੂੰ ਜਾਣਦੇ ਹਾਂ, ਅਸੀਂ ਬਲਾਕਾਂ ਦੇ ਪੱਤਰ-ਵਿਹਾਰ ਨੂੰ ਜਾਣਦੇ ਹਾਂ, ਅਸੀਂ ਵਸਤੂਆਂ ਦੇ ਨਾਮ ਜਾਣਦੇ ਹਾਂ - ਅਸੀਂ ਇੱਕ-ਨਾਲ-ਇੱਕ ਤੁਲਨਾ ਕਰਦੇ ਹਾਂ।


ਦੁਬਾਰਾ ਕੰਮ "ਇੱਕ ਤਾਰੇ ਨਾਲ". ਅਸੀਂ ਬੇਨਤੀ ਲੈਂਦੇ ਹਾਂ, ਇਸਨੂੰ ਲਾਗੂ ਕਰਦੇ ਹਾਂ, ਸਾਡੇ ਕੋਲ ਕੋਈ ਉਪਨਾਮ ਨਹੀਂ ਹੈ - ਅਸੀਂ ਇਸਨੂੰ ਇੱਕੋ CTE ਤੋਂ ਦੋ ਵਾਰ ਪੜ੍ਹਦੇ ਹਾਂ।


ਅਸੀਂ ਯੋਜਨਾ ਨੂੰ ਦੇਖਦੇ ਹਾਂ - ਸਮੱਸਿਆ ਕੀ ਹੈ? ਸਾਡੇ ਕੋਲ ਉਪਨਾਮ ਕਿਉਂ ਸੀ? ਅਸੀਂ ਇਸਨੂੰ ਆਰਡਰ ਨਹੀਂ ਕੀਤਾ। ਉਸਨੂੰ ਅਜਿਹਾ “ਨੰਬਰ ਨੰਬਰ” ਕਿੱਥੋਂ ਮਿਲਦਾ ਹੈ?

PostgreSQL ਇਸਨੂੰ ਆਪਣੇ ਆਪ ਜੋੜਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਬਸ ਇਸ ਨੂੰ ਸਮਝਣ ਦੀ ਲੋੜ ਹੈ ਸਿਰਫ਼ ਅਜਿਹਾ ਉਪਨਾਮ ਸਾਡੇ ਲਈ, ਯੋਜਨਾ ਨਾਲ ਤੁਲਨਾ ਕਰਨ ਦੇ ਉਦੇਸ਼ਾਂ ਲਈ, ਇਸਦਾ ਕੋਈ ਅਰਥ ਨਹੀਂ ਹੈ, ਇਸਨੂੰ ਇੱਥੇ ਬਸ ਜੋੜਿਆ ਗਿਆ ਹੈ। ਆਓ ਉਸ ਵੱਲ ਧਿਆਨ ਨਾ ਦੇਈਏ.

ਦੂਜਾ ਕੰਮ "ਇੱਕ ਤਾਰੇ ਨਾਲ": ਜੇਕਰ ਅਸੀਂ ਇੱਕ ਵਿਭਾਜਿਤ ਟੇਬਲ ਤੋਂ ਪੜ੍ਹ ਰਹੇ ਹਾਂ, ਤਾਂ ਸਾਨੂੰ ਇੱਕ ਨੋਡ ਮਿਲੇਗਾ Append ਜ Merge Append, ਜਿਸ ਵਿੱਚ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ “ਬੱਚੇ” ਸ਼ਾਮਲ ਹੋਣਗੇ, ਅਤੇ ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਕਿਸੇ ਨਾ ਕਿਸੇ ਤਰ੍ਹਾਂ ਹੋਵੇਗਾ Scan'ਓਮ ਟੇਬਲ-ਸੈਕਸ਼ਨ ਤੋਂ: Seq Scan, Bitmap Heap Scan ਜ Index Scan. ਪਰ, ਕਿਸੇ ਵੀ ਸਥਿਤੀ ਵਿੱਚ, ਇਹ "ਬੱਚੇ" ਗੁੰਝਲਦਾਰ ਸਵਾਲ ਨਹੀਂ ਹੋਣਗੇ - ਇਸ ਤਰ੍ਹਾਂ ਇਹਨਾਂ ਨੋਡਾਂ ਨੂੰ ਵੱਖ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ Append ਤੇ UNION.


ਅਸੀਂ ਅਜਿਹੀਆਂ ਗੰਢਾਂ ਨੂੰ ਵੀ ਸਮਝਦੇ ਹਾਂ, ਉਹਨਾਂ ਨੂੰ "ਇੱਕ ਢੇਰ ਵਿੱਚ" ਇਕੱਠਾ ਕਰਦੇ ਹਾਂ ਅਤੇ ਕਹਿੰਦੇ ਹਾਂ: "ਹਰ ਚੀਜ਼ ਜੋ ਤੁਸੀਂ ਮੇਗਾਟੇਬਲ ਤੋਂ ਪੜ੍ਹਦੇ ਹੋ ਉਹ ਇੱਥੇ ਅਤੇ ਰੁੱਖ ਦੇ ਹੇਠਾਂ ਹੈ".

"ਸਧਾਰਨ" ਡਾਟਾ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਨੋਡ

Values Scan ਯੋਜਨਾ ਵਿੱਚ ਮੇਲ ਖਾਂਦਾ ਹੈ VALUES ਬੇਨਤੀ ਵਿੱਚ.

Result ਬਿਨਾ ਇੱਕ ਬੇਨਤੀ ਹੈ FROM ਕ੍ਰਮਵਾਰ SELECT 1. ਜਾਂ ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਜਾਣਬੁੱਝ ਕੇ ਗਲਤ ਸਮੀਕਰਨ ਹੈ WHERE-ਬਲਾਕ (ਫਿਰ ਗੁਣ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ One-Time Filter):

EXPLAIN ANALYZE
SELECT * FROM pg_class WHERE FALSE; -- или 0 = 1

Result  (cost=0.00..0.00 rows=0 width=230) (actual time=0.000..0.000 rows=0 loops=1)
  One-Time Filter: false

Function Scan ਉਸੇ ਨਾਮ ਦੇ SRF ਲਈ “ਨਕਸ਼ੇ”।

ਪਰ ਨੇਸਟਡ ਸਵਾਲਾਂ ਦੇ ਨਾਲ ਸਭ ਕੁਝ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਹੈ - ਬਦਕਿਸਮਤੀ ਨਾਲ, ਉਹ ਹਮੇਸ਼ਾ ਵਿੱਚ ਨਹੀਂ ਬਦਲਦੇ InitPlan/SubPlan. ਕਈ ਵਾਰ ਉਹ ਵਿੱਚ ਬਦਲਦੇ ਹਨ ... Join ਜ ... Anti Join, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਤੁਸੀਂ ਕੁਝ ਅਜਿਹਾ ਲਿਖਦੇ ਹੋ WHERE NOT EXISTS .... ਅਤੇ ਇੱਥੇ ਉਹਨਾਂ ਨੂੰ ਜੋੜਨਾ ਹਮੇਸ਼ਾਂ ਸੰਭਵ ਨਹੀਂ ਹੁੰਦਾ - ਯੋਜਨਾ ਦੇ ਪਾਠ ਵਿੱਚ ਯੋਜਨਾ ਦੇ ਨੋਡਾਂ ਦੇ ਅਨੁਸਾਰੀ ਕੋਈ ਓਪਰੇਟਰ ਨਹੀਂ ਹਨ.

ਦੁਬਾਰਾ ਕੰਮ "ਇੱਕ ਤਾਰੇ ਨਾਲ": ਕੁੱਝ VALUES ਬੇਨਤੀ ਵਿੱਚ. ਇਸ ਕੇਸ ਵਿੱਚ ਅਤੇ ਯੋਜਨਾ ਵਿੱਚ ਤੁਹਾਨੂੰ ਕਈ ਨੋਡ ਮਿਲਣਗੇ Values Scan.


"ਗਿਣਤੀ" ਪਿਛੇਤਰ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਦੂਜੇ ਤੋਂ ਵੱਖ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਨਗੇ - ਉਹਨਾਂ ਨੂੰ ਉਸੇ ਤਰਤੀਬ ਵਿੱਚ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਅਨੁਸਾਰੀ ਪਾਏ ਜਾਂਦੇ ਹਨ VALUES- ਉੱਪਰ ਤੋਂ ਹੇਠਾਂ ਤੱਕ ਬੇਨਤੀ ਦੇ ਨਾਲ ਬਲਾਕ ਕਰਦਾ ਹੈ।

ਡਾਟਾ ਪ੍ਰੋਸੈਸਿੰਗ

ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਸਾਡੀ ਬੇਨਤੀ ਵਿੱਚ ਸਭ ਕੁਝ ਸੁਲਝਾਇਆ ਗਿਆ ਹੈ - ਜੋ ਕੁਝ ਬਚਿਆ ਹੈ Limit.


ਪਰ ਇੱਥੇ ਸਭ ਕੁਝ ਸਧਾਰਨ ਹੈ - ਜਿਵੇਂ ਕਿ ਨੋਡ Limit, Sort, Aggregate, WindowAgg, Unique ਬੇਨਤੀ ਵਿੱਚ ਸੰਬੰਧਿਤ ਆਪਰੇਟਰਾਂ ਨੂੰ “ਨਕਸ਼ਾ” ਇੱਕ-ਇੱਕ ਕਰਕੇ, ਜੇਕਰ ਉਹ ਉੱਥੇ ਹਨ। ਇੱਥੇ ਕੋਈ "ਤਾਰੇ" ਜਾਂ ਮੁਸ਼ਕਲਾਂ ਨਹੀਂ ਹਨ।

ਸ਼ਾਮਲ ਹੋਵੋ

ਜਦੋਂ ਅਸੀਂ ਜੋੜਨਾ ਚਾਹੁੰਦੇ ਹਾਂ ਤਾਂ ਮੁਸ਼ਕਲਾਂ ਪੈਦਾ ਹੁੰਦੀਆਂ ਹਨ JOIN ਆਪਣੇ ਆਪ ਵਿੱਚ. ਇਹ ਹਮੇਸ਼ਾ ਸੰਭਵ ਨਹੀਂ ਹੁੰਦਾ, ਪਰ ਇਹ ਸੰਭਵ ਹੈ.


ਪੁੱਛਗਿੱਛ ਪਾਰਸਰ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਸਾਡੇ ਕੋਲ ਇੱਕ ਨੋਡ ਹੈ JoinExpr, ਜਿਸ ਦੇ ਬਿਲਕੁਲ ਦੋ ਬੱਚੇ ਹਨ - ਖੱਬੇ ਅਤੇ ਸੱਜੇ। ਇਸ ਅਨੁਸਾਰ, ਇਹ ਉਹ ਹੈ ਜੋ ਤੁਹਾਡੀ ਸ਼ਾਮਲ ਹੋਣ ਦੇ "ਉੱਪਰ" ਹੈ ਅਤੇ ਬੇਨਤੀ ਵਿੱਚ "ਹੇਠਾਂ" ਕੀ ਲਿਖਿਆ ਗਿਆ ਹੈ।

ਅਤੇ ਯੋਜਨਾ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਇਹ ਕੁਝ ਦੇ ਦੋ ਵੰਸ਼ ਹਨ * Loop/* Join-ਨੋਡ. Nested Loop, Hash Anti Join,... - ਕੁੱਸ ਇਸ ਤਰ੍ਹਾਂ.

ਆਓ ਸਧਾਰਨ ਤਰਕ ਦੀ ਵਰਤੋਂ ਕਰੀਏ: ਜੇਕਰ ਸਾਡੇ ਕੋਲ ਟੇਬਲ A ਅਤੇ B ਹਨ ਜੋ ਯੋਜਨਾ ਵਿੱਚ ਇੱਕ ਦੂਜੇ ਨੂੰ "ਸ਼ਾਮਲ" ਕਰਦੇ ਹਨ, ਤਾਂ ਬੇਨਤੀ ਵਿੱਚ ਉਹ ਜਾਂ ਤਾਂ ਸਥਿਤ ਹੋ ਸਕਦੇ ਹਨ A-JOIN-B, ਜਾਂ B-JOIN-A. ਆਉ ਅਸੀਂ ਇਸ ਤਰੀਕੇ ਨਾਲ ਜੋੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ, ਆਉ ਦੂਜੇ ਤਰੀਕੇ ਨਾਲ ਜੋੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਉਦੋਂ ਤੱਕ ਜਦੋਂ ਤੱਕ ਅਸੀਂ ਅਜਿਹੇ ਜੋੜਿਆਂ ਤੋਂ ਬਾਹਰ ਨਹੀਂ ਜਾਂਦੇ.

ਚਲੋ ਆਪਣਾ ਸਿੰਟੈਕਸ ਟ੍ਰੀ ਲੈਂਦੇ ਹਾਂ, ਸਾਡੀ ਯੋਜਨਾ ਲੈਂਦੇ ਹਾਂ, ਉਹਨਾਂ ਨੂੰ ਦੇਖਦੇ ਹਾਂ... ਸਮਾਨ ਨਹੀਂ!


ਆਉ ਇਸਨੂੰ ਗ੍ਰਾਫਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਦੁਬਾਰਾ ਖਿੱਚੀਏ - ਓਹ, ਇਹ ਪਹਿਲਾਂ ਹੀ ਕੁਝ ਵਰਗਾ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ!


ਚਲੋ ਨੋਟ ਕਰੀਏ ਕਿ ਸਾਡੇ ਕੋਲ ਨੋਡ ਹਨ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਇੱਕੋ ਸਮੇਂ B ਅਤੇ C ਬੱਚੇ ਹਨ - ਸਾਨੂੰ ਇਸ ਗੱਲ ਦੀ ਪਰਵਾਹ ਨਹੀਂ ਹੈ ਕਿ ਕਿਸ ਕ੍ਰਮ ਵਿੱਚ। ਆਉ ਉਹਨਾਂ ਨੂੰ ਜੋੜਦੇ ਹਾਂ ਅਤੇ ਨੋਡ ਦੀ ਤਸਵੀਰ ਨੂੰ ਉਲਟਾ ਦਿੰਦੇ ਹਾਂ।


ਚਲੋ ਫਿਰ ਦੇਖੀਏ। ਹੁਣ ਸਾਡੇ ਕੋਲ ਬੱਚੇ A ਅਤੇ ਜੋੜਿਆਂ (B + C) ਦੇ ਨਾਲ ਨੋਡ ਹਨ - ਉਹਨਾਂ ਦੇ ਅਨੁਕੂਲ ਵੀ।


ਬਹੁਤ ਵਧੀਆ! ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਅਸੀਂ ਇਹ ਦੋ ਹਾਂ JOIN ਬੇਨਤੀ ਤੋਂ ਯੋਜਨਾ ਨੋਡਸ ਨੂੰ ਸਫਲਤਾਪੂਰਵਕ ਜੋੜਿਆ ਗਿਆ ਸੀ।

ਹਾਏ, ਇਸ ਸਮੱਸਿਆ ਦਾ ਹਮੇਸ਼ਾ ਹੱਲ ਨਹੀਂ ਹੁੰਦਾ।


ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਇੱਕ ਬੇਨਤੀ ਵਿੱਚ A JOIN B JOIN C, ਅਤੇ ਯੋਜਨਾ ਵਿੱਚ, ਸਭ ਤੋਂ ਪਹਿਲਾਂ, "ਬਾਹਰੀ" ਨੋਡ A ਅਤੇ C ਕਨੈਕਟ ਕੀਤੇ ਗਏ ਸਨ। ਪਰ ਬੇਨਤੀ ਵਿੱਚ ਅਜਿਹਾ ਕੋਈ ਆਪਰੇਟਰ ਨਹੀਂ ਹੈ, ਸਾਡੇ ਕੋਲ ਹਾਈਲਾਈਟ ਕਰਨ ਲਈ ਕੁਝ ਨਹੀਂ ਹੈ, ਕੋਈ ਸੰਕੇਤ ਜੋੜਨ ਲਈ ਕੁਝ ਨਹੀਂ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਲਿਖਦੇ ਹੋ ਤਾਂ "ਕਾਮਾ" ਨਾਲ ਵੀ ਇਹੀ ਹੁੰਦਾ ਹੈ A, B.

ਪਰ, ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਲਗਭਗ ਸਾਰੇ ਨੋਡਸ "ਖੁੱਲ੍ਹੇ" ਹੋ ਸਕਦੇ ਹਨ ਅਤੇ ਤੁਸੀਂ ਸਮੇਂ ਦੇ ਨਾਲ ਖੱਬੇ ਪਾਸੇ ਇਸ ਕਿਸਮ ਦੀ ਪ੍ਰੋਫਾਈਲਿੰਗ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ - ਸ਼ਾਬਦਿਕ, ਜਿਵੇਂ ਕਿ ਗੂਗਲ ਕਰੋਮ ਵਿੱਚ ਜਦੋਂ ਤੁਸੀਂ ਜਾਵਾਸਕ੍ਰਿਪਟ ਕੋਡ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦੇ ਹੋ। ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਹਰੇਕ ਲਾਈਨ ਅਤੇ ਹਰੇਕ ਸਟੇਟਮੈਂਟ ਨੂੰ "ਐਕਜ਼ੀਕਿਊਟ" ਕਰਨ ਵਿੱਚ ਕਿੰਨਾ ਸਮਾਂ ਲੱਗਾ।


ਅਤੇ ਤੁਹਾਡੇ ਲਈ ਇਸ ਸਭ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਵਧੇਰੇ ਸੁਵਿਧਾਜਨਕ ਬਣਾਉਣ ਲਈ, ਅਸੀਂ ਸਟੋਰੇਜ ਬਣਾਈ ਹੈ ਪੁਰਾਲੇਖ, ਜਿੱਥੇ ਤੁਸੀਂ ਸੁਰੱਖਿਅਤ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਸੰਬੰਧਿਤ ਬੇਨਤੀਆਂ ਦੇ ਨਾਲ ਆਪਣੀਆਂ ਯੋਜਨਾਵਾਂ ਲੱਭ ਸਕਦੇ ਹੋ ਜਾਂ ਕਿਸੇ ਨਾਲ ਲਿੰਕ ਸਾਂਝਾ ਕਰ ਸਕਦੇ ਹੋ।

ਜੇਕਰ ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਨਾ-ਪੜ੍ਹਨਯੋਗ ਪੁੱਛਗਿੱਛ ਨੂੰ ਢੁਕਵੇਂ ਰੂਪ ਵਿੱਚ ਲਿਆਉਣ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਵਰਤੋਂ ਕਰੋ ਸਾਡਾ "ਸਧਾਰਨ ਕਰਨ ਵਾਲਾ".

ਸਰੋਤ: www.habr.com