PostgreSQL ਐਂਟੀਪੈਟਰਨ: ਹਾਨੀਕਾਰਕ JOINs ਅਤੇ ORs

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

PG ਦੇ ਕੁਝ ਬਾਅਦ ਵਾਲੇ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਸਥਿਤੀ ਬਦਲ ਸਕਦੀ ਹੈ ਕਿਉਂਕਿ ਸ਼ਡਿਊਲਰ ਚੁਸਤ ਬਣ ਜਾਂਦਾ ਹੈ, ਪਰ 9.4/9.6 ਲਈ ਇਹ ਲਗਭਗ ਉਹੀ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਇੱਥੇ ਦਿੱਤੀਆਂ ਉਦਾਹਰਣਾਂ ਵਿੱਚ।

ਆਓ ਇੱਕ ਬਹੁਤ ਹੀ ਅਸਲ ਬੇਨਤੀ ਕਰੀਏ:

SELECT
  TRUE
FROM
  "Документ" d
INNER JOIN
  "ДокументРасширение" doc_ex
    USING("@Документ")
INNER JOIN
  "ТипДокумента" t_doc ON
    t_doc."@ТипДокумента" = d."ТипДокумента"
WHERE
  (d."Лицо3" = 19091 or d."Сотрудник" = 19091) AND
  d."$Черновик" IS NULL AND
  d."Удален" IS NOT TRUE AND
  doc_ex."Состояние"[1] IS TRUE AND
  t_doc."ТипДокумента" = 'ПланРабот'
LIMIT 1;

ਸਾਰਣੀ ਅਤੇ ਖੇਤਰ ਦੇ ਨਾਮ ਬਾਰੇਖੇਤਾਂ ਅਤੇ ਟੇਬਲਾਂ ਦੇ "ਰੂਸੀ" ਨਾਮਾਂ ਨੂੰ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਸਮਝਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਸੁਆਦ ਦਾ ਮਾਮਲਾ ਹੈ. ਕਿਉਂਕਿ ਦ ਇੱਥੇ Tensor 'ਤੇ ਇੱਥੇ ਕੋਈ ਵਿਦੇਸ਼ੀ ਡਿਵੈਲਪਰ ਨਹੀਂ ਹਨ, ਅਤੇ PostgreSQL ਸਾਨੂੰ ਹਾਇਰੋਗਲਿਫਸ ਵਿੱਚ ਵੀ ਨਾਮ ਦੇਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਜੇਕਰ ਉਹ ਹਵਾਲੇ ਵਿੱਚ ਨੱਥੀ ਹੈ, ਫਿਰ ਅਸੀਂ ਅਸਪਸ਼ਟ ਅਤੇ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਵਸਤੂਆਂ ਨੂੰ ਨਾਮ ਦੇਣਾ ਪਸੰਦ ਕਰਦੇ ਹਾਂ ਤਾਂ ਜੋ ਕੋਈ ਅੰਤਰ ਨਾ ਹੋਵੇ।
ਆਓ ਨਤੀਜਾ ਯੋਜਨਾ ਨੂੰ ਵੇਖੀਏ:

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

144ms ਅਤੇ ਲਗਭਗ 53K ਬਫਰ - ਯਾਨੀ 400MB ਤੋਂ ਵੱਧ ਡਾਟਾ! ਅਤੇ ਅਸੀਂ ਖੁਸ਼ਕਿਸਮਤ ਹੋਵਾਂਗੇ ਜੇਕਰ ਉਹ ਸਾਰੇ ਸਾਡੀ ਬੇਨਤੀ ਦੇ ਸਮੇਂ ਤੱਕ ਕੈਸ਼ ਵਿੱਚ ਹਨ, ਨਹੀਂ ਤਾਂ ਡਿਸਕ ਤੋਂ ਪੜ੍ਹੇ ਜਾਣ 'ਤੇ ਕਈ ਗੁਣਾ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੱਗੇਗਾ।

ਐਲਗੋਰਿਦਮ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਹੈ!

ਕਿਸੇ ਵੀ ਬੇਨਤੀ ਨੂੰ ਕਿਸੇ ਤਰ੍ਹਾਂ ਅਨੁਕੂਲ ਬਣਾਉਣ ਲਈ, ਤੁਹਾਨੂੰ ਪਹਿਲਾਂ ਇਹ ਸਮਝਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਇਸਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਆਉ ਹੁਣੇ ਲਈ ਇਸ ਲੇਖ ਦੇ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ ਡੇਟਾਬੇਸ ਢਾਂਚੇ ਦੇ ਵਿਕਾਸ ਨੂੰ ਛੱਡ ਦੇਈਏ, ਅਤੇ ਸਹਿਮਤ ਹਾਂ ਕਿ ਅਸੀਂ ਮੁਕਾਬਲਤਨ "ਸਸਤੇ" ਕਰ ਸਕਦੇ ਹਾਂ ਬੇਨਤੀ ਨੂੰ ਮੁੜ ਲਿਖੋ ਅਤੇ/ਜਾਂ ਕੁਝ ਚੀਜ਼ਾਂ ਨੂੰ ਬੇਸ ਉੱਤੇ ਰੋਲ ਕਰੋ ਜਿਨ੍ਹਾਂ ਦੀ ਸਾਨੂੰ ਲੋੜ ਹੈ ਸੂਚਕਾਂਕ.

ਇਸ ਲਈ ਬੇਨਤੀ:
— ਘੱਟੋ-ਘੱਟ ਕੁਝ ਦਸਤਾਵੇਜ਼ ਦੀ ਮੌਜੂਦਗੀ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ
- ਜਿਸ ਸਥਿਤੀ ਵਿੱਚ ਸਾਨੂੰ ਲੋੜ ਹੈ ਅਤੇ ਇੱਕ ਖਾਸ ਕਿਸਮ ਦੀ
- ਜਿੱਥੇ ਲੇਖਕ ਜਾਂ ਕਲਾਕਾਰ ਉਹ ਕਰਮਚਾਰੀ ਹੈ ਜਿਸਦੀ ਸਾਨੂੰ ਲੋੜ ਹੈ

ਸ਼ਾਮਲ ਹੋਵੋ + ਸੀਮਾ 1

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

ਆਓ ਪਹਿਲਾਂ "ਦਸਤਾਵੇਜ਼ ਕਿਸਮ" ਟੇਬਲ ਦੇ ਨਾਲ ਕੁਨੈਕਸ਼ਨ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾਈਏ, ਅਤੇ ਉਸੇ ਸਮੇਂ ਡੇਟਾਬੇਸ ਨੂੰ ਦੱਸੋ ਕਿ ਸਾਡਾ ਟਾਈਪ ਰਿਕਾਰਡ ਵਿਲੱਖਣ ਹੈ (ਅਸੀਂ ਇਹ ਜਾਣਦੇ ਹਾਂ, ਪਰ ਸ਼ਡਿਊਲਰ ਨੂੰ ਅਜੇ ਤੱਕ ਕੋਈ ਜਾਣਕਾਰੀ ਨਹੀਂ ਹੈ):

WITH T AS (
  SELECT
    "@ТипДокумента"
  FROM
    "ТипДокумента"
  WHERE
    "ТипДокумента" = 'ПланРабот'
  LIMIT 1
)
...
WHERE
  d."ТипДокумента" = (TABLE T)
...

ਹਾਂ, ਜੇਕਰ ਸਾਰਣੀ/ਸੀਟੀਈ ਵਿੱਚ ਇੱਕ ਸਿੰਗਲ ਰਿਕਾਰਡ ਦਾ ਇੱਕ ਖੇਤਰ ਸ਼ਾਮਲ ਹੈ, ਤਾਂ ਪੀਜੀ ਵਿੱਚ ਤੁਸੀਂ ਇਸ ਦੀ ਬਜਾਏ ਇਸ ਤਰ੍ਹਾਂ ਵੀ ਲਿਖ ਸਕਦੇ ਹੋ

d."ТипДокумента" = (SELECT "@ТипДокумента" FROM T LIMIT 1)

PostgreSQL ਸਵਾਲਾਂ ਵਿੱਚ ਆਲਸੀ ਮੁਲਾਂਕਣ

BitmapOr ਬਨਾਮ UNION

ਕੁਝ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਬਿਟਮੈਪ ਹੀਪ ਸਕੈਨ ਸਾਡੇ ਲਈ ਬਹੁਤ ਖਰਚ ਕਰੇਗਾ - ਉਦਾਹਰਨ ਲਈ, ਸਾਡੀ ਸਥਿਤੀ ਵਿੱਚ, ਜਦੋਂ ਬਹੁਤ ਸਾਰੇ ਰਿਕਾਰਡ ਲੋੜੀਂਦੀ ਸ਼ਰਤ ਨੂੰ ਪੂਰਾ ਕਰਦੇ ਹਨ। ਸਾਨੂੰ ਇਹ ਮਿਲਿਆ ਕਿਉਂਕਿ OR ਸ਼ਰਤ BitmapOr ਵਿੱਚ ਬਦਲ ਗਈ- ਯੋਜਨਾ ਵਿੱਚ ਕਾਰਵਾਈ.
ਆਉ ਮੂਲ ਸਮੱਸਿਆ ਵੱਲ ਵਾਪਸ ਚਲੀਏ - ਸਾਨੂੰ ਇਸ ਨਾਲ ਸੰਬੰਧਿਤ ਰਿਕਾਰਡ ਲੱਭਣ ਦੀ ਲੋੜ ਹੈ ਕੋਈ ਵੀ ਸ਼ਰਤਾਂ ਤੋਂ - ਭਾਵ, ਦੋਵਾਂ ਸ਼ਰਤਾਂ ਅਧੀਨ ਸਾਰੇ 59K ਰਿਕਾਰਡਾਂ ਦੀ ਖੋਜ ਕਰਨ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ। ਇੱਕ ਸ਼ਰਤ ਨੂੰ ਬਾਹਰ ਕੰਮ ਕਰਨ ਦਾ ਇੱਕ ਤਰੀਕਾ ਹੈ, ਅਤੇ ਦੂਜੇ ਉੱਤੇ ਉਦੋਂ ਹੀ ਜਾਓ ਜਦੋਂ ਪਹਿਲੀ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਮਿਲਿਆ. ਹੇਠਾਂ ਦਿੱਤਾ ਡਿਜ਼ਾਈਨ ਸਾਡੀ ਮਦਦ ਕਰੇਗਾ:

(
  SELECT
    ...
  LIMIT 1
)
UNION ALL
(
  SELECT
    ...
  LIMIT 1
)
LIMIT 1

"ਬਾਹਰੀ" ਸੀਮਾ 1 ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਖੋਜ ਉਦੋਂ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ ਜਦੋਂ ਪਹਿਲਾ ਰਿਕਾਰਡ ਮਿਲਦਾ ਹੈ। ਅਤੇ ਜੇਕਰ ਇਹ ਪਹਿਲਾਂ ਹੀ ਪਹਿਲੇ ਬਲਾਕ ਵਿੱਚ ਪਾਇਆ ਗਿਆ ਹੈ, ਤਾਂ ਦੂਜੇ ਬਲਾਕ ਨੂੰ ਚਲਾਇਆ ਨਹੀਂ ਜਾਵੇਗਾ (ਕਦੇ ਨਹੀਂ ਚਲਾਇਆ ਗਿਆ ਦੇ ਸਬੰਧ ਵਿੱਚ).

"ਕੇਸ ਦੇ ਤਹਿਤ ਮੁਸ਼ਕਲ ਹਾਲਾਤਾਂ ਨੂੰ ਲੁਕਾਉਣਾ"

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

SELECT
  ...
FROM
  "Документ" d
WHERE
  ... /*index cond*/ AND
  CASE
    WHEN "$Черновик" IS NULL AND "Удален" IS NOT TRUE THEN (
      SELECT
        "Состояние"[1] IS TRUE
      FROM
        "ДокументРасширение"
      WHERE
        "@Документ" = d."@Документ"
    )
  END

ਇੱਕ ਵਾਰ ਸਾਡੇ ਲਈ ਲਿੰਕਡ ਟੇਬਲ ਤੋਂ ਨਤੀਜੇ ਲਈ ਕਿਸੇ ਵੀ ਖੇਤਰ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਫਿਰ ਸਾਡੇ ਕੋਲ ਸਬਕਵੇਰੀ 'ਤੇ JOIN ਨੂੰ ਇੱਕ ਸ਼ਰਤ ਵਿੱਚ ਬਦਲਣ ਦਾ ਮੌਕਾ ਹੈ।
ਚਲੋ ਇੰਡੈਕਸਡ ਖੇਤਰਾਂ ਨੂੰ "ਕੇਸ ਬਰੈਕਟਾਂ ਦੇ ਬਾਹਰ" ਛੱਡ ਦੇਈਏ, ਰਿਕਾਰਡ ਤੋਂ WHEN ਬਲਾਕ ਵਿੱਚ ਸਧਾਰਨ ਸ਼ਰਤਾਂ ਜੋੜੋ - ਅਤੇ ਹੁਣ "ਭਾਰੀ" ਪੁੱਛਗਿੱਛ ਕੇਵਲ THEN ਨੂੰ ਪਾਸ ਕਰਨ 'ਤੇ ਹੀ ਚਲਾਈ ਜਾਂਦੀ ਹੈ।

ਮੇਰਾ ਆਖਰੀ ਨਾਮ "ਕੁੱਲ" ਹੈ

ਅਸੀਂ ਉੱਪਰ ਦੱਸੇ ਗਏ ਸਾਰੇ ਮਕੈਨਿਕਸ ਨਾਲ ਨਤੀਜੇ ਵਜੋਂ ਪੁੱਛਗਿੱਛ ਨੂੰ ਇਕੱਠਾ ਕਰਦੇ ਹਾਂ:

WITH T AS (
  SELECT
    "@ТипДокумента"
  FROM
    "ТипДокумента"
  WHERE
    "ТипДокумента" = 'ПланРабот'
)
  (
    SELECT
      TRUE
    FROM
      "Документ" d
    WHERE
      ("Лицо3", "ТипДокумента") = (19091, (TABLE T)) AND
      CASE
        WHEN "$Черновик" IS NULL AND "Удален" IS NOT TRUE THEN (
          SELECT
            "Состояние"[1] IS TRUE
          FROM
            "ДокументРасширение"
          WHERE
            "@Документ" = d."@Документ"
        )
      END
    LIMIT 1
  )
UNION ALL
  (
    SELECT
      TRUE
    FROM
      "Документ" d
    WHERE
      ("ТипДокумента", "Сотрудник") = ((TABLE T), 19091) AND
      CASE
        WHEN "$Черновик" IS NULL AND "Удален" IS NOT TRUE THEN (
          SELECT
            "Состояние"[1] IS TRUE
          FROM
            "ДокументРасширение"
          WHERE
            "@Документ" = d."@Документ"
        )
      END
    LIMIT 1
  )
LIMIT 1;

ਸੂਚਕਾਂਕ ਨੂੰ [ਵਿੱਚ] ਵਿਵਸਥਿਤ ਕਰਨਾ

ਇੱਕ ਸਿਖਿਅਤ ਅੱਖ ਨੇ ਦੇਖਿਆ ਕਿ UNION ਸਬ-ਬਲਾਕਾਂ ਵਿੱਚ ਸੂਚਕਾਂਕ ਸਥਿਤੀਆਂ ਥੋੜ੍ਹੀਆਂ ਵੱਖਰੀਆਂ ਹਨ - ਇਹ ਇਸ ਲਈ ਹੈ ਕਿਉਂਕਿ ਸਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਟੇਬਲ 'ਤੇ ਢੁਕਵੇਂ ਸੂਚਕਾਂਕ ਹਨ। ਅਤੇ ਜੇ ਉਹ ਮੌਜੂਦ ਨਹੀਂ ਸਨ, ਤਾਂ ਇਹ ਬਣਾਉਣ ਦੇ ਯੋਗ ਹੋਵੇਗਾ: ਦਸਤਾਵੇਜ਼(Person3, Documenttype) и ਦਸਤਾਵੇਜ਼ (ਦਸਤਾਵੇਜ਼ ਦੀ ਕਿਸਮ, ਕਰਮਚਾਰੀ).
ROW ਹਾਲਤਾਂ ਵਿੱਚ ਖੇਤਰਾਂ ਦੇ ਕ੍ਰਮ ਬਾਰੇਯੋਜਨਾਕਾਰ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਬੇਸ਼ਕ, ਤੁਸੀਂ ਲਿਖ ਸਕਦੇ ਹੋ (A, B) = (constA, constB)ਅਤੇ (B, A) = (constB, constA). ਪਰ ਜਦੋਂ ਰਿਕਾਰਡਿੰਗ ਸੂਚਕਾਂਕ ਵਿੱਚ ਖੇਤਰਾਂ ਦੇ ਕ੍ਰਮ ਵਿੱਚ, ਅਜਿਹੀ ਬੇਨਤੀ ਬਾਅਦ ਵਿੱਚ ਡੀਬੱਗ ਕਰਨ ਲਈ ਵਧੇਰੇ ਸੁਵਿਧਾਜਨਕ ਹੈ।
ਯੋਜਨਾ ਵਿੱਚ ਕੀ ਹੈ?

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

ਬਦਕਿਸਮਤੀ ਨਾਲ, ਅਸੀਂ ਬਦਕਿਸਮਤ ਸੀ ਅਤੇ ਪਹਿਲੇ UNION ਬਲਾਕ ਵਿੱਚ ਕੁਝ ਵੀ ਨਹੀਂ ਮਿਲਿਆ, ਇਸਲਈ ਦੂਜੇ ਨੂੰ ਅਜੇ ਵੀ ਚਲਾਇਆ ਗਿਆ ਸੀ। ਪਰ ਫਿਰ ਵੀ - ਕੇਵਲ 0.037ms ਅਤੇ 11 ਬਫਰ!
ਅਸੀਂ ਬੇਨਤੀ ਨੂੰ ਤੇਜ਼ ਕੀਤਾ ਹੈ ਅਤੇ ਮੈਮੋਰੀ ਵਿੱਚ ਡਾਟਾ ਪੰਪਿੰਗ ਨੂੰ ਘਟਾ ਦਿੱਤਾ ਹੈ ਕਈ ਹਜ਼ਾਰ ਵਾਰ, ਕਾਫ਼ੀ ਸਧਾਰਨ ਤਕਨੀਕਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ - ਥੋੜ੍ਹੇ ਜਿਹੇ ਕਾਪੀ-ਪੇਸਟ ਦੇ ਨਾਲ ਇੱਕ ਵਧੀਆ ਨਤੀਜਾ. 🙂

ਸਰੋਤ: www.habr.com