🚀 go-pugleaf

On Sat, 12 Dec 2015 10:52:51 -0800 (PST), M.M. wrote:

>>> mechanizmu niż indeksy, to inne rozwiązanie też będzie zabójcze.
>>> Wyszukiwanie przez index hash jest bardzo szybkie, więc inne rozwiązania
>>> będą szybsze maksymalnie 3-4 razy i to tylko na silnikach które mają
>>> coś lepszego niż indeksy.
>> 
>> Inne rozwiązania będą szybsze setki razy :-)
> Analiza jest skomplikowana. Na czas zapytania składa się kilka czynników:
> 1) Transfer danych
> 2) Parsowanie zapytania
> 3) Optymalizowanie i sposób wykonania.
> 4) Dostępy do danych w buforze ram
> 5) Dostępy do danych na dysku
> 6) Odczyty danych z dysku.

Ok, ok, ale... to wszystko bez znaczenia, bo występuje w każdym wypadku.
Pisząc o "innych rozwiązaniach" miałem na myśli inaczej zbudowany SQL
(select), niż to co pokazałeś. Bo albo ja nie rozumiem co masz na myśli,
albo Ty nie rozumiesz jak serwer tego typu zapytanie wykonuje.

> Jeden dysk (SSD) ma 100tys dostępów na sekundę, drugi tylko 100. Każda
> strategia na każdym dysku da inne przyspieszenie.

Mówimy cały czas o jednym i niezmiennym środowisku, porównywanie wydajności
rozwiązania na różnym hardware jest bezcelowe i bezowocne.
 
> Spójrzmy skrótowo. Dostęp do danych zaindeksowanych wymaga 3-4 odczytow z
> dysku. Dostęp optymalny wymaga jednego odczytu. Czyli teoretycznie można
> przyspieszyć nie więcej niż 3-4 razy. A jeśli optymalizator opracuje
> tak kosztowny plan wykonania że faktycznie można przyspieszyć setki
> razy, to mi ręce opadają i używam innego rozwiązania.

Chodziło o zwykłe:

select L.imie, L.Nazwisko, count(z.id) as liczba_samochodow from Ludzie L
join zasoby z on z.id_1 = L.id
join samochody s on s.id = z.id_2 
group by L.imie, L.nazwisko
 
Tylko dzięki takiej budowie zapytania (w przeciwieństwie do Twojego)
zyskujesz potwornie na wydajności. 

>> PS. oczywiście mogę nie wiedzieć, że istnieje serwer SQL, który zrozumie co
>> autor miał na myśli i wykona to zapytanie zupełnie inaczej niż autor mu
>> kazał.
> Od tego jest optymalizator, żeby zrobić tę robotę za autora. Dopracujesz
> szczegóły, baza zmieni zawartość i architekturę i znowu będziesz dopracowywał?
> To ja wolę dopracować np. w C++.

No wiesz, nie wszystko się da jednak zoptymalizować. Programista też musi
myśleć. Doczytałem, że Oracle coś tam umie keszować przy zapytaniu tego
typu jaki zaprezentowałeś (nazywają to scalar subquery), ale warunkiem jest
powtarzalność rekordów z tabeli bazowej (tu: Ludzie), a to nie zawsze jest
spełniony warunek (tu nie jest).

-- 
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ę"