🚀 go-pugleaf

A.L.E.C wrote:
> Mam zapytanie SQL, które wg explain wykonuje się poniżej 1 ms:
> 
> SELECT n.id, d.userid, d.id AS dataid
> FROM phonenumbers n
> JOIN phonenumberassignments a ON (a.phonenumberid = n.id)
> LEFT JOIN phonecontractdata d ON (d.id = a.phonecontractdataid)
> WHERE (n.number = ? OR (n.number < ? AND n.number_end >= ?))
> AND d.vdate <= ?
> AND (d.todate IS NULL OR d.todate > ?)
> AND d.status = 1
> ORDER BY d.vdate DESC, d.id DESC
> LIMIT 1;

Tak wygląda explain:

Limit  (cost=47.57..47.57 rows=1 width=16) (actual time=0.126..0.126 rows=1 loops=1)
   ->  Sort  (cost=47.57..47.57 rows=1 width=16) (actual time=0.125..0.125 rows=1 loops=1)
         Sort Key: d.vdate, d.id
         Sort Method:  quicksort  Memory: 25kB
         ->  Nested Loop  (cost=34.86..47.56 rows=1 width=16) (actual time=0.110..0.115 rows=1 loops=1)
               ->  Nested Loop  (cost=34.86..47.18 rows=1 width=8) (actual time=0.097..0.099 rows=1 loops=1)
                     ->  Bitmap Heap Scan on phonenumbers n  (cost=34.86..38.88 rows=1 width=4) (actual time=0.083..0.083 rows=1 loops=1)
                           Recheck Cond: ((number = 221248415) OR ((number < 221248415) AND (number_end >= 221248415)))
                           ->  BitmapOr  (cost=34.86..34.86 rows=1 width=0) (actual time=0.078..0.078 rows=0 loops=1)
                                 ->  Bitmap Index Scan on phonenumbers_number_key  (cost=0.00..4.29 rows=1 width=0) (actual time=0.017..0.017 rows=1 loops=1)
                                       Index Cond: (number = 221248415)
                                 ->  Bitmap Index Scan on phonenumbers_number_key  (cost=0.00..30.57 rows=1 width=0) (actual time=0.059..0.059 rows=0 loops=1)
                                       Index Cond: ((number < 221248415) AND (number_end >= 221248415))
                     ->  Index Scan using phonenumberassignments_phonenumberid_idx on phonenumberassignments a  (cost=0.00..8.29 rows=1 width=8) (actual time=0.009..0.009 rows=1 loops=1)
                           Index Cond: (a.phonenumberid = n.id)
               ->  Index Scan using phonecontractdata_pkey on phonecontractdata d  (cost=0.00..0.36 rows=1 width=12) (actual time=0.011..0.012 rows=1 loops=1)
                     Index Cond: (d.id = a.phonecontractdataid)
                     Filter: ((d.vdate <= '2009-03-23'::date) AND ((d.todate IS NULL) OR (d.todate > '2009-03-23'::date)) AND (d.status = 1))
Total runtime: 0.224 ms

Aktualnie doszedłem do tego że to samo zapytanie przygotowane przy pomocy prepare/execute
ale bez parametrów działa szybko - 0.001 sek. Teraz pytanie czy to problem
prepared_statements w postgresie, czy DBI? Sprawdzę w php.

-- 
Aleksander 'A.L.E.C' Machniak http://alec.pl gg:2275252
LAN Management System Developer http://lms.org.pl
Roundcube Webmail Project Developer http://roundcube.net

On 2009-05-08, A.L.E.C <alec1@poczta.onet.pl> wrote:
> Aktualnie doszedłem do tego że to samo zapytanie przygotowane przy pomocy prepare/execute
> ale bez parametrów działa szybko - 0.001 sek. Teraz pytanie czy to problem
> prepared_statements w postgresie, czy DBI? Sprawdzę w php.

zobaczy czy to nie to cię "ugryzło":
http://www.depesz.com/index.php/2008/05/10/prepared-statements-gotcha/

depesz

-- 
Linkedin: http://www.linkedin.com/in/depesz  /  blog: http://www.depesz.com/
jid/gtalk: depesz@depesz.com / aim:depeszhdl / skype:depesz_hdl / gg:6749007

>  Aktualnie doszedłem do tego że to samo zapytanie przygotowane przy pomocy prepare/execute
>  ale bez parametrów działa szybko - 0.001 sek. Teraz pytanie czy to problem
>  prepared_statements w postgresie, czy DBI? Sprawdzę w php.

Wykonanie zapytania "gotowego", a wykonanie przez preapre/execute to
trochę coś innego. Jeśli chcesz zrobić analizę tego co jest wywoływane
przez DBI, musisz puścić explain trochę inaczej. Przygotuj sobie
zapytanie w psql za pomocą:

PREPARE test (typy parametrów) AS zapytanie;

potem wykonaj:

EXPLAIN ANALYZE EXECUTE test(parametry);

Plan wykonania dla zapytania "gotowego" potrafi się różnić od planu
dla PREPARE/EXECUTE, stąd te różnice w czasach wykonia (planer dla
zapytania "gotowego" wie jakich parametrów używasz, a dla PREPARE/EXECUTE
nie wie w momencie "preparowanie", więc czasem pewnych rzeczy nie
jest w stanie zoptymalizować).

-- 
Daniel Podlejski

hubert depesz lubaczewski wrote:

> zobaczy czy to nie to cię "ugryzło":
> http://www.depesz.com/index.php/2008/05/10/prepared-statements-gotcha/

Tak, dokładnie, niestety nie pomaga ani rzutowanie na odpowiednie typy, 
ani zdefiniowanie typów parametrów przy PREPARE. Trochę mnie to smuci, 
bo aplikacja którą piszę wykonuje prawie wszystkie zapytania przez 
prepare/execute z parametrami.

-- 
Aleksander 'A.L.E.C' Machniak http://alec.pl gg:2275252
LAN Management System Developer http://lms.org.pl
Roundcube Webmail Developer http://roundcube.net