Re: [postgresql-it] Problema performance query
- From: "Riccardo (SCASI)" <r.penco@xxxxxxxxxxxx>
- To: postgresql-it@xxxxxxxxxxxxx
- Date: Wed, 16 Apr 2008 14:03:11 +0200
Chris Mair ha scritto:
certo, eccole
interessante...
quel giorno aggiunto suggerisce di usare un query plan
*del tutto* diverso: salta all'occhio il sort di mezzo:
Sort (...rows=3015...) (actual ...rows=304670...)
ovvero, il planner s'aspetta di avere 3k rows li` e invece
trova 300k.
Prova ad allargare il campionamento statistico delle
colonne id_rilev, datain. Devi fare un po` di prove:
alter table dettagliorilevamenti alter id_rilev set statistics 100;
alter table rilevamenti alter datain set statistics 100;
analyze dettagliorilevamenti;
analyze rilevamenti;
Ora come va?
centrato!!!
con statistics a 100, mettendo molti giorni in più (1 mese):
Aggregate (cost=336982.50..336982.51 rows=1 width=0) (actual
time=50842.178..50842.178 rows=1 loops=1)
-> Nested Loop (cost=0.00..334666.62 rows=926351 width=0) (actual
time=0.048..49998.286 rows=963886 loops=1)
-> Index Scan using idx_data on rilevamenti r
(cost=0.00..4592.44 rows=9115 width=8) (actual time=0.024..474.263
rows=8221 loops=1)
Index Cond: ((datain >= '2007-11-01 00:00:00'::timestamp
without time zone) AND (datain <= '2007-12-01 00:00:00'::timestamp
without time zone))
-> Index Scan using idx_rilev on dettagliorilevamenti dr
(cost=0.00..28.02 rows=655 width=4) (actual time=2.267..5.825 rows=117
loops=8221)
Index Cond: ("outer".id = dr.id_rilev)
Total runtime: 50842.284 ms
(al secondo run impiega 4103 ms)
una domanda, come hai scelto i campi per cui aumentare il campionamento
statistico?
[...]
Bye,
Chris.
ciao e grazie 1k
riki
Other related posts:
