Wydajność selekta czyli SELECT `model.*` FROM `model`

Chodzi mi po głowie pewne nurtujące pytanie od dłuższego czasu, mianowicie jak przedstawia się wydajność z SELECT’em gdy wyciągamy dane z bazy.

W logach jest coś takiego:

Place Load (0.5ms) SELECT `places`.* FROM `places` CACHE (0.0ms) SELECT `places`.* FROM `places`
Czyli:
SELECT * from places;

Z tego co pamiętam, to zawszę na studiach potwarzali mi żeby robić wyselekcjonowanego selekta i nie wyciągać zbędnych śmieci, nie obciążać bazy. np:
SELECT id, cos, name FROM places;

Pytanie
Jeśli np tabela places zawierała by dużo pól typu text np 5(które nie są potrzebne do wyświetlenia np w index), to mam rozumieć że podczas SELECT places.* FROM places były by one pobierane?

No jak widzisz w logach tak właśnie jest ;] Jest tworzony obiekt w pamięci i z niego później wyciągasz co chcesz, jeśli uważasz że masz tak olbrzymią aplikację w której musisz się tym martwić to możesz użyć :select i wyciagnąć tylko to co chcesz

Mógłbyś rozwinąć?
W tym poradniku nic nie ma odnośnie :select
http://guides.rubyonrails.org/active_record_querying.html
Select poprzez SQL?

Na studiach uczą dużej ilości cargo cult. Niestety nie uczą najważniejszego: benchmarks or it didn’t happen.

Nigdy nie optymalizuj na wyrost. Najpierw napisz działającą aplikację. Później ustal jak szybko ma działać (np. 100ms per request). Potem wstaw benchmarki do kodu i popatrz gdzie są wolne operacje.

Jak się szybko przekonasz większość czasu w Rails zżera renderowanie. Jeśli query SQL jest obciążeniem to najczęściej ze względu na skomplikowane łączenie wielu tabel, brak indeksów i wyliczeniowe warunki w where, które wymagają przejścia po wszystkich rekordach zamiast korzystać z indeksów. Samo wyciąganie danych nie jest wąskim gardłem - prędzej zarżniesz swoją aplikację wyciągając za dużo rekordów niż za dużo kolumn.

Nie przejmuj się teraz i nie próbuj optymalizować na zaś dopóki nie masz w ręku dobrych numerków - na co w Twoim systemie idzie czas i moc procesora.

Jest, tutaj: http://guides.rubyonrails.org/active_record_querying.html#selecting-specific-fields

Ale tak jak napisał Bargi, póki aplikacja działa wystarczająco wydajnie, nie zajmuj się takimi rzeczami.

Ja np ostatnio poległem na tym, że wyciaganie danych z bazy trwało parę milisekund a zamienienie ich na obiekty AR kilka sekund w zależności od wyciągnietych kolumn.
Obiektów wyciąganych z bazy było parę tysięcy.

Przykładowe dane : http://pastie.org/private/rxj9bqilnxoi0ezgglryfg
Jak widać duży problem to kolumny z datami jeśli chodzi o zamiane baza => ar …

Niemniej i tak największym problemem okazało się wspomniane przez Bragiego renderowanie…

@paneq pamiętam z RuPy jak ktoś mówił, że opłaca się korzystać z jakiegoś gema, który daje przepisane klasy Date/Time w C. Dokladnie juz tematu nie pamietam http://blog.pluron.com/2009/04/ruby-date-class.html

Kojarzę temat, ale zamierzamy przesiąść się na JRuby więc nie chcę nawet tracić czasu na próbowanie.