Czy Oracle jest tak głupi, czy mi brakuje wiedzy...

0

Potrzebuje sobie posortowac pewien zbior danych z selecta (naprawde jest to sporo joinow i kilkadziesit tysiecy rekordow wynikowych, ale dla uproszczenia nieche bedzie jeden select :P), a nastepnie przyciac go do 100 pierwszych.

Postgres: Uzywam LIMIT i jest to wszystko bardzo wydajne

Oracle: Musze cale moje query "oblozyc" query zewnetrzenym i zrobic WHERE rownum < 100 - jest to okropnie zabojdze dla wydajnosci....

Nie chce mi się wierzyć, że nie można zrobićtego inteligentniej (widzialem ze w oracle 12.1 jest nowa klauzula, ale potrzebuje tego pod 11)

0

Nie ma innej drogi. Ale co do wydajności to nie bardzo widzę jak może ją psuć. Wygeneruj plan zapytania bo myśle że problem leży w innym miejscu...

0

nie ma teraz tego pod reka.

ale to samo zapytanie z limit pod postgresem w ulamek sekundy.
a identyczne zapytanie bez limit oblozone query z rownum kilkadziesiat sekund.

wiec plan zapytanie chyba nie wiele pomoze (postgres jakos mogl o to samo w dobrej kolejnosci odpytac, wiec czemu oracle robilby to nieoptymalnie ?)

1

jeśli zapytanie muli (i nie jest odpalone na 10 letnim kompie i/lub nie masz bazy wielkości terabajtów) to problemem jest twój brak wiedzy. Samo ograniczanie ilości zwróconych rekordów przez podzapytanie nie ma tu żadnego znaczenia. Po pierwsze baza musi złożyć twoje zapytanie do kupy a potem posortować je bo przecież te "pierwsze 100" jest pierwsze wg jakiegoś klucza. Najpierw zrób (zmień zapytanie /dodaj zmień indeksy) tak aby główne zapytanie działało prawidłowo a potem dodaj ograniczenie do 100 rekordów. Pierwsze co powinieneś zrobić to przyjrzeć się planowi zapytania a nie lecieć na forum z żalami. Po pleckach cię mamy poklepać? Bo chyba nie liczysz na konkrety nie pokazując ani DDLa ani SQLa ani planu

0

w tym postgresie i oraclu masz tyle samo rekordów, takie same schemy ?
indeksy na oraclu są pozakładane ?
jeżeli myślisz że poznanie planu zapytania ci nic nie pomoże to raczej problem leży w tobie a nie w bazie danych
odpal go i zobacz czy gdzieś nie leci full table scan bo nie ma indeksu

ps. to że masz limit to dużego znaczenia nie ma, za nim jakakolwiek baza zwróci ci te 100 rekordów to najpierw musi wszystkie posortować lub znaleźć największe w indeksie

0

to jest moje prywatne wiec nie moge pokazac.

to nie jest takie proste zapytanie.

Indeksy sa wszedzie gdzie trzeba

Dla jednego z selectow jest warunek (jest kilka joinow) where cosTam IS NULL (left joinem). W tym konkretnym wypadku zapytanie zwraca kilkadziesiat tysiecy rekordow dla ktorych praktycznie wszystkie maja spelniony warunek IS NULL - to jest zabojcze dla bazy, bo ona musi wykonac takie sprawdzanie zanim zrobi limit do 1000... co wynika z prymitywnosci (bo jak to inaczej nazwac skladni oracla)

0

mam indeksy, plan zapytanie z tego co pamietam wygladal w porzadku (jutro jeszcze popatrze)

sortowanie nie jest tu problemem, ale sprawdzanie IS NULL przed limitem... (tylko w oracle, bo nie ma LIMIT tylko skaldnia z podzapytaniem)

0

Wygeneruj plan i zobaczysz jak baza chce to liczyć. Innej rady nie ma :)

0

@walec51 ok, ale chyba mi nie powiesz (abstrachujac od problemu), ze brak klauzuli LIMIT, a koniecznosc uzycia dodatkowego query w nadquery to nieulomnosc jezyka w tej kwestii, a jakis fajny, elegancki feature :P

0

i jeszcze jedno, nie mam planu zapytanie teraz przed oczami ale jeszcze jedno na chlopski rozum:

POSTGRES:

Ok, posortowalem 100tys, rekordow (szybko) i teraz zwroce 1000 pierwszych ktorych pole 'x' jest null, byloby wolno, ale jest LIMIT 1000 wiec pojdzie nienajgorzej

ORACLE:

Ok, posortowalem 100tys, rekordow (szybko), ale co ten glupi user chce, musze teraz WSZYSTKO przeleciec, i zwrocic te gdzie 'x' jest nullem (no co, napocę się ale zrobie). Minelo duzo czasu. Aha jestem teraz w nadquery (poziom wyzej) i zwroce szybciutko 1000 pierwszych...

I tu jest wlasnie pies pogrzebany...

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0