PostgreSQL ക്വറി പ്രൊഫൈലർ: പ്ലാനും അന്വേഷണവും എങ്ങനെ പൊരുത്തപ്പെടുത്താം

ഇതിനകം ഉപയോഗിക്കുന്ന പലരും വിശദീകരിക്കുക.tensor.ru - ഞങ്ങളുടെ PostgreSQL പ്ലാൻ വിഷ്വലൈസേഷൻ സേവനത്തിന് അതിന്റെ സൂപ്പർ പവറുകളിലൊന്നിനെക്കുറിച്ച് അറിയില്ലായിരിക്കാം - സെർവർ ലോഗിന്റെ വായിക്കാൻ പ്രയാസമുള്ള ഒരു ഭാഗം മാറ്റുന്നു...

... അനുബന്ധ പ്ലാൻ നോഡുകൾക്കായി സന്ദർഭോചിതമായ സൂചനകളോടെ മനോഹരമായി രൂപകൽപ്പന ചെയ്ത അന്വേഷണത്തിലേക്ക്:

അദ്ദേഹത്തിന്റെ രണ്ടാം ഭാഗത്തിന്റെ ഈ ട്രാൻസ്ക്രിപ്റ്റിൽ PGConf.Russia 2020-ൽ റിപ്പോർട്ട് ഞങ്ങൾ ഇത് എങ്ങനെ ചെയ്തുവെന്ന് ഞാൻ നിങ്ങളോട് പറയും.

ആദ്യ ഭാഗത്തിന്റെ ട്രാൻസ്ക്രിപ്റ്റ്, സാധാരണ അന്വേഷണ പ്രകടന പ്രശ്നങ്ങൾക്കും അവയുടെ പരിഹാരങ്ങൾക്കും വേണ്ടി സമർപ്പിച്ചിരിക്കുന്നത്, ലേഖനത്തിൽ കാണാം "അസുഖമുള്ള SQL അന്വേഷണങ്ങൾക്കുള്ള പാചകക്കുറിപ്പുകൾ".

ആദ്യം, നമുക്ക് കളറിംഗ് ആരംഭിക്കാം - ഞങ്ങൾ ഇനി പ്ലാൻ കളർ ചെയ്യില്ല, ഞങ്ങൾ ഇതിനകം തന്നെ നിറം നൽകി, ഞങ്ങൾക്ക് ഇതിനകം തന്നെ മനോഹരവും മനസ്സിലാക്കാവുന്നതുമാണ്, പക്ഷേ ഒരു അഭ്യർത്ഥന.

അത്തരമൊരു ഫോർമാറ്റ് ചെയ്യാത്ത “ഷീറ്റ്” ഉപയോഗിച്ച് ലോഗിൽ നിന്ന് വലിച്ചെടുത്ത അഭ്യർത്ഥന വളരെ വൃത്തികെട്ടതും അതിനാൽ അസൗകര്യവുമാണെന്ന് ഞങ്ങൾക്ക് തോന്നി.


പ്രത്യേകിച്ചും ഡവലപ്പർമാർ കോഡിലെ അഭ്യർത്ഥനയുടെ ബോഡി ഒരു വരിയിൽ "പശ" ചെയ്യുമ്പോൾ (ഇത് തീർച്ചയായും ഒരു ആന്റിപാറ്റേൺ ആണ്, പക്ഷേ ഇത് സംഭവിക്കുന്നു). ഭയങ്കരം!

ഇത് എങ്ങനെയെങ്കിലും കൂടുതൽ മനോഹരമായി വരയ്ക്കാം.


നമുക്ക് ഇത് മനോഹരമായി വരയ്ക്കാൻ കഴിയുമെങ്കിൽ, അതായത്, അഭ്യർത്ഥനയുടെ ബോഡി ഡിസ്അസംബ്ലിംഗ് ചെയ്‌ത് വീണ്ടും ഒരുമിച്ച് ചേർക്കാൻ കഴിയുമെങ്കിൽ, ഈ അഭ്യർത്ഥനയുടെ ഓരോ ഒബ്‌ജക്റ്റിലേക്കും നമുക്ക് ഒരു സൂചന "അറ്റാച്ച്" ചെയ്യാം - പ്ലാനിലെ അനുബന്ധ പോയിന്റിൽ എന്താണ് സംഭവിച്ചത്.

ചോദ്യം വാക്യഘടന ട്രീ

ഇത് ചെയ്യുന്നതിന്, അഭ്യർത്ഥന ആദ്യം പാഴ്‌സ് ചെയ്യണം.


കാരണം നമുക്കുണ്ട് സിസ്റ്റത്തിന്റെ കാതൽ NodeJS-ൽ പ്രവർത്തിക്കുന്നു, അതിനുശേഷം ഞങ്ങൾ അതിനായി ഒരു മൊഡ്യൂൾ ഉണ്ടാക്കി, നിങ്ങൾക്ക് കഴിയും GitHub-ൽ അത് കണ്ടെത്തുക. വാസ്തവത്തിൽ, ഇവ PostgreSQL പാർസറിന്റെ ഇന്റേണലുകളിലേക്ക് വിപുലീകരിച്ച "ബൈൻഡിംഗുകൾ" ആണ്. അതായത്, വ്യാകരണം ലളിതമായി ബൈനറി കംപൈൽ ചെയ്യുകയും NodeJS-ൽ നിന്ന് ബൈൻഡിംഗുകൾ ഉണ്ടാക്കുകയും ചെയ്യുന്നു. ഞങ്ങൾ മറ്റുള്ളവരുടെ മൊഡ്യൂളുകൾ അടിസ്ഥാനമായി എടുത്തു - ഇവിടെ വലിയ രഹസ്യമൊന്നുമില്ല.

ഞങ്ങളുടെ ഫംഗ്‌ഷനിലേക്കുള്ള ഇൻപുട്ടായി അഭ്യർത്ഥനയുടെ ബോഡി ഞങ്ങൾ നൽകുന്നു - ഔട്ട്‌പുട്ടിൽ നമുക്ക് JSON ഒബ്‌ജക്റ്റിന്റെ രൂപത്തിൽ ഒരു പാഴ്‌സ് ചെയ്‌ത വാക്യഘടന ട്രീ ലഭിക്കും.


ഇപ്പോൾ നമുക്ക് ഈ ട്രീയിലൂടെ എതിർദിശയിൽ ഓടുകയും നമുക്ക് ആവശ്യമുള്ള ഇൻഡന്റുകൾ, കളറിംഗ്, ഫോർമാറ്റിംഗ് എന്നിവ ഉപയോഗിച്ച് ഒരു അഭ്യർത്ഥന കൂട്ടിച്ചേർക്കുകയും ചെയ്യാം. ഇല്ല, ഇത് ഇഷ്‌ടാനുസൃതമാക്കാവുന്നതല്ല, പക്ഷേ ഇത് സൗകര്യപ്രദമാണെന്ന് ഞങ്ങൾക്ക് തോന്നി.

മാപ്പിംഗ് അന്വേഷണവും പ്ലാൻ നോഡുകളും

ആദ്യ ഘട്ടത്തിൽ വിശകലനം ചെയ്ത പ്ലാനും രണ്ടാമത്തേതിൽ വിശകലനം ചെയ്ത ചോദ്യവും എങ്ങനെ സംയോജിപ്പിക്കാമെന്ന് നോക്കാം.

നമുക്ക് ഒരു ലളിതമായ ഉദാഹരണമെടുക്കാം - ഒരു CTE സൃഷ്ടിക്കുകയും അതിൽ നിന്ന് രണ്ടുതവണ വായിക്കുകയും ചെയ്യുന്ന ഒരു ചോദ്യം ഞങ്ങളുടെ പക്കലുണ്ട്. അവൻ അത്തരമൊരു പദ്ധതി തയ്യാറാക്കുന്നു.

.മാരെജിനു

നിങ്ങൾ ഇത് ശ്രദ്ധാപൂർവ്വം നോക്കുകയാണെങ്കിൽ, പതിപ്പ് 12 വരെ (അല്ലെങ്കിൽ കീവേഡ് ഉപയോഗിച്ച് അതിൽ നിന്ന് ആരംഭിക്കുന്നു MATERIALIZED) രൂപീകരണം പ്ലാനർക്ക് CTE ഒരു സമ്പൂർണ്ണ തടസ്സമാണ്.


ഇതിനർത്ഥം, അഭ്യർത്ഥനയിൽ എവിടെയെങ്കിലും ഒരു CTE തലമുറയും പ്ലാനിൽ എവിടെയെങ്കിലും ഒരു നോഡും കാണുകയാണെങ്കിൽ CTE, അപ്പോൾ ഈ നോഡുകൾ തീർച്ചയായും പരസ്പരം "യുദ്ധം" ചെയ്യുന്നു, നമുക്ക് അവയെ ഉടനടി സംയോജിപ്പിക്കാൻ കഴിയും.

ഒരു നക്ഷത്രചിഹ്നത്തിലെ പ്രശ്നം: CTE കൾ കൂടുണ്ടാക്കാം.

വളരെ മോശമായി നെസ്റ്റഡ് ചെയ്തവയും അതേ പേരിലുള്ളവയും ഉണ്ട്. ഉദാഹരണത്തിന്, നിങ്ങൾക്ക് അകത്ത് കഴിയും CTE A ഉണ്ടാക്കുക CTE X, അകത്ത് അതേ തലത്തിൽ CTE B വീണ്ടും ചെയ്യുക CTE X:

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

താരതമ്യം ചെയ്യുമ്പോൾ, നിങ്ങൾ ഇത് മനസ്സിലാക്കണം. “നിങ്ങളുടെ കണ്ണുകൊണ്ട്” ഇത് മനസ്സിലാക്കുന്നത് - പ്ലാൻ കാണുന്നത് പോലും, അഭ്യർത്ഥനയുടെ ബോഡി കാണുന്നത് പോലും - വളരെ ബുദ്ധിമുട്ടാണ്. നിങ്ങളുടെ CTE തലമുറ സങ്കീർണ്ണവും കൂടുകൂട്ടിയതും അഭ്യർത്ഥനകൾ വലുതും ആണെങ്കിൽ, അത് പൂർണ്ണമായും അബോധാവസ്ഥയിലാണ്.

UNION

അന്വേഷണത്തിൽ ഒരു കീവേഡ് ഉണ്ടെങ്കിൽ 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 at 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-JOIN-B, അല്ലെങ്കിൽ B-JOIN-A. നമുക്ക് ഈ രീതിയിൽ സംയോജിപ്പിക്കാൻ ശ്രമിക്കാം, നമുക്ക് മറ്റൊരു വഴി കൂട്ടിച്ചേർക്കാൻ ശ്രമിക്കാം, അങ്ങനെയുള്ള ജോഡികൾ തീരുന്നത് വരെ.

നമുക്ക് നമ്മുടെ വാക്യഘടന എടുക്കാം, നമ്മുടെ പ്ലാൻ എടുക്കാം, അവരെ നോക്കൂ... സമാനമല്ല!


നമുക്ക് ഇത് ഗ്രാഫുകളുടെ രൂപത്തിൽ വീണ്ടും വരയ്ക്കാം - ഓ, ഇത് ഇതിനകം എന്തോ പോലെ തോന്നുന്നു!


ഒരേസമയം കുട്ടികളുള്ള ബിയും സിയും ഉള്ള നോഡുകൾ ഞങ്ങളുടെ പക്കലുണ്ടെന്ന കാര്യം ശ്രദ്ധിക്കുക - ഏത് ക്രമത്തിൽ ഞങ്ങൾ ശ്രദ്ധിക്കുന്നില്ല. നമുക്ക് അവയെ സംയോജിപ്പിച്ച് നോഡിന്റെ ചിത്രം തിരിക്കാം.


ഒന്നുകൂടി നോക്കാം. ഇപ്പോൾ ഞങ്ങൾക്ക് കുട്ടികൾ എയും ജോഡികളും (ബി + സി) ഉള്ള നോഡുകൾ ഉണ്ട് - അവയ്ക്കും അനുയോജ്യമാണ്.


കൊള്ളാം! ഇത് നമ്മൾ രണ്ടുപേരാണെന്ന് മാറുന്നു JOIN പ്ലാൻ നോഡുകളുമായുള്ള അഭ്യർത്ഥനയിൽ നിന്ന് വിജയകരമായി സംയോജിപ്പിച്ചു.

അയ്യോ, ഈ പ്രശ്നം എല്ലായ്പ്പോഴും പരിഹരിക്കപ്പെടുന്നില്ല.


ഉദാഹരണത്തിന്, ഒരു അഭ്യർത്ഥനയിലാണെങ്കിൽ A JOIN B JOIN C, കൂടാതെ പ്ലാനിൽ, ഒന്നാമതായി, "ഔട്ടർ" നോഡുകൾ എ, സി എന്നിവ ബന്ധിപ്പിച്ചിരിക്കുന്നു. എന്നാൽ അഭ്യർത്ഥനയിൽ അത്തരമൊരു ഓപ്പറേറ്റർ ഇല്ല, ഞങ്ങൾക്ക് ഹൈലൈറ്റ് ചെയ്യാൻ ഒന്നുമില്ല, ഒരു സൂചനയും അറ്റാച്ചുചെയ്യാൻ ഒന്നുമില്ല. നിങ്ങൾ എഴുതുമ്പോൾ "കോമ" പോലെ തന്നെ A, B.

പക്ഷേ, മിക്ക കേസുകളിലും, മിക്കവാറും എല്ലാ നോഡുകളും "കെട്ടഴിച്ചേക്കാം" കൂടാതെ നിങ്ങൾക്ക് യഥാസമയം ഇടതുവശത്ത് ഇത്തരത്തിലുള്ള പ്രൊഫൈലിംഗ് ലഭിക്കും - അക്ഷരാർത്ഥത്തിൽ, നിങ്ങൾ ജാവാസ്ക്രിപ്റ്റ് കോഡ് വിശകലനം ചെയ്യുമ്പോൾ Google Chrome ലെ പോലെ. ഓരോ വരിയും ഓരോ പ്രസ്താവനയും "എക്സിക്യൂട്ട്" ചെയ്യാൻ എത്ര സമയമെടുത്തുവെന്ന് നിങ്ങൾക്ക് കാണാൻ കഴിയും.


നിങ്ങൾക്ക് ഇതെല്ലാം ഉപയോഗിക്കുന്നത് കൂടുതൽ സൗകര്യപ്രദമാക്കുന്നതിന്, ഞങ്ങൾ സ്റ്റോറേജ് ഉണ്ടാക്കിയിട്ടുണ്ട് ആർക്കൈവ്, ബന്ധപ്പെട്ട അഭ്യർത്ഥനകൾക്കൊപ്പം നിങ്ങളുടെ പ്ലാനുകൾ സംരക്ഷിക്കാനും പിന്നീട് കണ്ടെത്താനും അല്ലെങ്കിൽ മറ്റൊരാളുമായി ലിങ്ക് പങ്കിടാനും കഴിയുന്നിടത്ത്.

നിങ്ങൾക്ക് വായിക്കാൻ കഴിയാത്ത ഒരു ചോദ്യം മതിയായ രൂപത്തിൽ കൊണ്ടുവരണമെങ്കിൽ, ഉപയോഗിക്കുക ഞങ്ങളുടെ "നോർമലൈസർ".

അവലംബം: www.habr.com