Optymalizacja sortowania po danych z JOIN Opcje

[DeyV]

Mam problem

Proste zapytanie, typu:

[SQL] pobierz, plaintext 
SELECT dane.*, 
user.*
FROM dane LEFT JOIN user ON ( user.id = dane.userid )
ORDER BY dane.DATA
LIMIT 50
[SQL] pobierz, plaintext 

przy poprawnie założonych indexach wykonuje się bardzo szybko.


Czasem jednak pojawia się konieczność posortowania takiego wyniku po danych z tabeli łączonej, np. w tym przykładzie, po nazwisku usera.

I wtedy okazuje się, że żaden index nie chce pomóc, bo pobierane są wszystkie dane z "dane", wtedy wykonywane jest złączenie i dopiero wtedy - wykonywane jest sortowanie i limit.
(zakładając że w "dane" są setki tyś rekordów takie rozwiązanie jest naprawdę bardzo kosztowne :/ )

Czy jesteście w stanie zaproponować jakiekolwiek sposób na optymalizację takiego zapytania?

[SongoQ]

Nie mam jak tego sprawdzic moze odwroc sytuacje index na sortowanie i ta tabelke jako glowna w zlaczeniu i do tego right join. Napisz co pokazuje explain w tym i w tym.

[DeyV]

tak - to byłoby najprostsze rozwiązanie.
Niestety - zapomniałem dodać, że pozostała struktura zapytania, nie związana z tym problemem, nie pozwala na zmianę kolejności łączeń.

Tj. zawsze user musi być łączony do data, nie odwrotnie.

[SongoQ]

Co sie nauswa na mysl to wymusic w pierwszej kolejnosci ten index a pozniej reszta niech sobie leci tak jak optymalizator robi.

[DeyV]

jakieś sugestie jak ?

[SongoQ]

Mozesz kilka rzeczy zastosowac:
np SET ENABLE_SEQSCAN TO OFF; lub vacum. Z tego co wygooglowalem to nieraz takie problemy sie zdarzaly w starszej wersji pg ze dla w miare prostych rzeczy uzywal pelnego skanowania.

Mozesz podeslac bardziej szczegolowe dane i explain?

PG to nie ORACLE gdzie mozesz dowolny hint zastosowac.

[Sedziwoj]

Coś nie do końca rozumiem problem, ale nie można użyć pod zapytania z sortowaniem złączenia i znów sortowania?

[dr_bonzo]

Albo zlaczyc Usera z Danymi INNER JOINEM i do tego union tych rekordow z Danych gdzie nie ma usera przypisanego?

[SongoQ]

Podejrzewam ze union do tego da wiekszy koszt niz sam join.

@DeyV Udalo CI sie to rozwiazac?