» »

[PLPGSQL] Pocasen query

[PLPGSQL] Pocasen query

BigWhale ::

A je kak PLPGSQL expert tle in mi lahko razlozi zakaj query

... FROM foo WHERE occured >= _date_from AND occured <= _date_to

traja ful manj casa (1.5sec vs 65sec) kot:

... FROM foo WHERE occured >= _date_from

Plot twist1: _date_to je postavljen v prihodnost in ga noben record ne matcha. V tabeli je kakih 30mio recordov.

Plot twist2: Vse skupi je v stored proceduri wrapped v FOR row IN ... LOOP RETURN NEXT row END LOOP in ce query pozenem v command line-u potem dela povsem normalno.

brodul ::

 occured <= _date_to 

je vedno res, ce prav razumem?
Pretending to be a mature adult is so exhausting.

fiction ::

Nimam pojma, ampak toliko, da bo mogoče komu drugemu lažje pri diagnosticiranju:

ce query pozenem v command line-u potem dela povsem normalno
...potem oba querija trajata ~1.5s?

Kaj pa kakšna varianta z:
...AND true
oz. nek izraz z _date_to, ki je vedno resničen. Je tudi pri tem kakšna razlika?

fiction ::

Naivno si predstavljam, da je enkrat naredil "sequential scan", drugič pa uporabil index na occured or sth. Se pravi bi mogoče tudi koristilo, če bi razkril še kakšne indekse imaš.

EXPLAIN ANALYZE?

Pa mogoče lahko poskusiš z
If you believe the optimizer is incorrect in choosing a sequential scan, use SET enable_seqscan TO 'off' and run query again to see if an index scan is indeed faster.
(Postgres FAQ)

BigWhale ::

SET enable_seqscan=false;

Je uredilo problem.

V primeru, z dvema parametroma se je delal index scan po tabeli, samo z enim pa je delal sequential scan.

Hvala Sergio. :)

Zgodovina sprememb…

  • spremenil: BigWhale ()

fiction ::

Jah ok to je workaround, ni pa prava rešitev. Mene je zdaj začelo zanimati, zakaj je query optimizer zafrknil oz. zakaj je to naredil samo v scopu FOR LOOP-a, sicer pa očitno ne.

BigWhale ::

Ja, to tudi mene zanima zakaj je tko bebavo izbral. Mogoce je predvideval, da bo moj loop dalj casa trajal? Dejansko se pa zavrti samo trikrat.

Tole je vse kar je v funkciji:
FOR row IN
  SELECT type, COUNT(*)
    FROM events
      WHERE occured >= _date_from
      GROUP BY type ORDER BY type
LOOP
  RETURN NEXT row;
END LOOP;
RETURN;


Mogoce zaradi grupiranja misli da bo sequential scan hitrejsi. Nevem. Explain analyze na sami funkciji ne pokaze nic pametnega. Verjetno bi ga moral pognati v sami funkciji?

MrStein ::

Oracle ima možnost gledanja plan-a za dejansko izveden query.
Če ima pgsql kaj takega, bi bilo za pogledat.

O tem, da se optimizer odloči za slabo strategijo, pa so verjetno že cele knjige napisane... :P
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Zgodovina sprememb…

  • spremenil: MrStein ()


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

sql, php date between periodično/letno

Oddelek: Programiranje
251419 (845) mr_chai
»

PL SQL problem

Oddelek: Programiranje
15918 (487) killa bee
»

C - shranjevanje rezultatov iz baze v array

Oddelek: Programiranje
71220 (919) Randomness
»

SQL Parent key not found

Oddelek: Programiranje
71060 (983) Ciklamen
»

3dmark06 rezultat

Oddelek: Pomoč in nasveti
9938 (615) smarty

Več podobnih tem