🚀 go-pugleaf

On Thursday, December 17, 2015 at 9:25:07 AM UTC-5, szemrany wrote:
> On Wed, 16 Dec 2015 07:43:51 -0800 (PST), M.M. wrote:
> 
> > On Wednesday, December 16, 2015 at 4:37:05 PM UTC+1, szemrany wrote:
> >> On Wed, 16 Dec 2015 05:36:44 -0800 (PST), M.M. wrote:
> >> 
> >>>> Chodziło mi o to, że każdy kolejny JOIN eliminuje przetwarzane rekordy i
> >>>> zawęża zbiór przetwarzanych danych, tym samym ogranicza liczbę odczytów z
> >>>> pliku. 
> >>> Ok, a jakie z kolei jest tego uzasadnienie? Moim zdaniem operacje wykonywane w
> >>> joinie wymagają takiego samego przetworzenia jak w podzapytaniu.
> >> 
> >> Się wpakowałem z tym "setki razy" i teraz mnie do tablicy wzywasz każąc
> >> odpowiadać na trudne pytania ;-)
> > Spokojnie, ja tylko chcę się dowiedzieć. Kiedyś ktoś mi powiedział 
> > tak samo i uwierzyłem na słowo. Potem w praktyce było różnie. Pomyślałem że
> > może znasz uzasadnienie. Może to działa w jakiś szczególnych warunkach... 
> > Jeśli nie znasz uzasadnienia, to rozumiem, nie będę dopytywał.
> > 
> > 
> > 
> >> http://stackoverflow.com/questions/1788678/sql-sub-query-or-inner-join
> >> 
> >> To nie jest wyjaśnienie szczegółowe, ale o to samo mi chodzi. 
> >> Szukam ciągle potwierdzenia jakiegoś bardziej "naukowego", ale póki co nie
> >> znalazłem nic na tyle wiarygodnego by było niepodważalne.
> > 
> > Hmmm może to jest mit?
> 
> No to się poświęciłem i zamiast zajmować się pracą robiłem testy, oto
> wyniki "badań" przeprowadzonych na serwerze Firebird 2.5:
> 
> http://snap.ashampoo.com/uploads/2015-12-17/ns9NcBYp.png
> 
> Po lewej Twoja wersja zapytania, po prawej z joinami.
> 
> A to realne odczyty wykonane przez serwer:
> 
> http://snap.ashampoo.com/uploads/2015-12-17/IQiC574j.png
> 
> 
> -- 
> howgh
> szemrany
> "Trzeba z żywymi naprzód iść, po życie sięgać nowe,
> a nie w uwiędłych laurów liść z uporem stroić głowę"

No i dzieki poswieceniu kolegi dowiedzielismy sie ze idiotyczne zapytanie zabije serwer (prosze nie traktowac tego jako osobista wycieczke - kolega po prostu sprawdzil ze "garbage in -> garbage out").
Juz na pierwszy rzut oka widac ze pierwsze zapytanie bedzie sie wykonywalo w niesamowicie dlugi sposob dzieki full scan na tabelach - do tego nawet nie potrzeba analizowac planu wykonania.