Results 1 to 9 of 9

Thread: Wat kost een "onnodige" join

  1. #1

    Wat kost een "onnodige" join

    Hallo hallo,

    In mijn applicatie heb ik zoekfunctie ingebouwd waarbij de FROM clausule statisch is en de WHERE en de SELECT clausules dynamisch gevuld worden vanuit mijn applicatie. Nu kunnen er in de FROM clausule redelijk wat left inner en outer joins komen te staan, die in sommige gevallen (waarschijnlijk zelfs in de meeste gevallen) overbodig zullen zijn. Nu vroeg ik me af of dit qua performance iets gaat uitmaken of dat het weg geoptimaliseerd wordt?

    Ik gebruikt voor mijn project Postgres 10, maar ik ben zeker ook geïnteresseerd in hoe dit bij andere databases geregeld is.

    Bij voorbaat dank!

  2. #2
    In basis geldt: Er is geen peil op te trekken.

    Een inner join is in mijn ervaring (met Oracle, voornamelijk) vaak sneller dan een outer join (of minstens net zo snel), als deze daadwerkelijk gebruikt wordt. Dat heeft dan weer iets te maken met hoe de indexes gebruikt worden. De database kan eerst kijken welke rijen überhaupt gebruikt worden o.b.v. de join, voordat het zwaardere werk gedaan moet worden.

    Een outer join is in mijn ervaring vaak makkelijker weg te optimaliseren als deze niet gebruikt wordt, d.w.z. niet in de where clause en niet in de geselecteerde velden. Een outer join heeft namelijk verder geen (weinig) effect op het eindresultaat. Er worden geen rijen gefilterd op basis van die join, hooguit verdubbeld. Ook dat verschilt weer per database. MySQL lijkt veel efficienter te werken met left joins dan met inner joins, terwijl het in Oracle andersom lijkt te zijn.

    Maar het precieze effect is meestal niet zo groot, en is naast de opbouw van de query ook erg afhankelijk van je database + versie, platform, structuur van en hoeveelheid data, inclusief onderliggende hardware en andere omgevingsfactoren. M.a.w: testen, testen, testen. En als een bepaalde variant ineens erg tegenvalt qua performance, dan kan je die onder de loep nemen en kijken of je het execution plan kan verbeteren door bijvoorbeeld indexes aan te passen, index hints toe te voegen (als Postgres zoiets kent), of de query anders te schrijven.
    1+1=b

  3. #3
    In basis geldt: Er is geen peil op te trekken.
    Daar was ik al bang voor.

    Ik heb inmiddels het één en ander getest en die onnodige joins lijken in ieder geval niet veel te kosten. Mocht het in de praktijk toch tegenvallen, dan schrijf ik zelf wel wat code die de query vereenvoudigd (Mijn queries zijn vrij simpel in dit specifieke geval).

    Bedankt!

  4. #4
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    (Indien niet door de SQL plan maker geëlimineerd kan ook excessieve locking veroorzaken. Dat merk je echter pas als je echt contention hebt)

  5. #5
    Die snap ik niet Marco. Eventuele problemen met locking krijg je toch pas als je op die joins gaat updaten?

  6. #6
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Nee. Ook bij reads (ik weet het zeker van MS SQL 2003 of 2005, daar heb ik een hoop zij effectief readonly tabelletjes(1 update per kwartaal) moeten nolock-en. Ik zie ook bij serieuze apps mysql wel eens "with nolock" staan )

    Waarom weet ik niet, en ik kan er alleen een slag naar slaan gebaseerd op hoe planners werken.

    Mogelijk dat het van het isolatie niveau afhangt, en dat als het hoog genoeg is, maar de sql planner weinig row access verwacht dat ie besluit dat globaal locken makkelijker is dan een staat administratie opbouwen voor rowlocks om read-commited en hoger af te handelen.

    Ik heb op SQLServer forums in ieder geval gevonden dat het probleem met promotie van rowlocks naar global tabel locks te maken heeft.

    Als zulke tabel dan heel veel gebruikt wordt in queries met heel veel tabellen (was toen toch al gauw 15 gemiddeld), krijg je een contentie en een soort philosopher's diner probleem met effectief serializatie van queries. Je zag in de log constant deadlocks en restarts van de query. Magnitudes aan performance verlies.

    Overigens is dit allemaal 15 jaar geleden, en vind ik een tabel toevoegen in postgres nu al lastig en complex DB werk. (:-)
    Last edited by marcov; 23-Aug-19 at 15:26.

  7. #7
    In DBISAM is het gebruik van "generate plan" een goede methode om inzicht te krijgen in sommige "kosten" Net even gezocht maar er is ook zoiets in postgres met "EXPLAIN" https://www.postgresql.org/docs/9.3/using-explain.html Misschien dat dat helpt om het antwoord te vinden?

  8. #8
    Voor wie interesse heeft: ik gebruik nooit outer joins, enkel inner joins en dat zorgt ervoor dat de SQL-statements een stuk eenvoudiger zijn en meestal sneller.
    De verbazing begint waar de kennis ophoudt

  9. #9
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Wat Goleztrol zegt is IMHO zinnig. Als de join niet gebruikt wordt in de criteria (of in een chain van joins), dan kan de query plan maker de outer join naar achteren duwen, zodat alleen bij de resultaat items de outer join berekent wordt. Als daar dan ook nog een index voor is, kan het snel gaan.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •