Re:

> -----Ursprüngliche Nachricht-----
> Von: pgsql-de-allgemein-owner(at)postgresql(dot)org [mailto:pgsql-de-allgemein-
> owner(at)postgresql(dot)org] Im Auftrag von Albe Laurenz
> Gesendet: Mittwoch, 23. Mai 2012 16:19
> An: Andreas Kretschmer *EXTERN*; pgsql-de-allgemein(at)postgresql(dot)org
> Betreff: Re: [pgsql-de-allgemein]
>
> Andreas Kretschmer schrieb:
> > Am 23.05.2012 11:06, schrieb Gülümser Köroglu:
> [...]
> >> Indices auf dieser Tabelle:
> >>
> >> CREATE INDEX ndalarmhistory_20000000_action_ix
> >> ON ndalarmhistory_20000000
> >> USING btree
> >> (action , ndalarm_id , actiontime DESC);
> >>
> >>
> >>
> >> CREATE INDEX ndalarmhistory__20000000_actiontime_ix
> >> ON ndalarmhistory_20000000
> >> USING btree
> >> (actiontime DESC);
> >>
> >>
> >> Abfrage:
> >> select ActionTime from NDAlarmHistory where Action = 0 AND
> >> NDAlarm_id ='56' order by actiontime desc limit 1
>
> >> Explain Anlayze liefert (constraint_exclusion = on):
> >>
> [...]
> >> " -> Index Scan using ndalarmhistory_0_actionime_ix on
> ndalarmhistory_0 ndalarmhistory (cost=0.00..1085.45 rows=1 width=8)
> (actual time=0.136..0.136 rows=0 loops=1)"
> >> " Filter: ((action = 0) AND (ndalarm_id =
> 56::bigint))"
> >> " -> Index Scan using
> ndalarmhistory_15000000_actionime_ix on ndalarmhistory_15000000
> ndalarmhistory (cost=0.00..22130.41 rows=1 width=8) (actual
> time=158.244..158.244 rows=0 loops=1)"
> >> " Filter: ((action = 0) AND (ndalarm_id =
> 56::bigint))"
> >> " -> Index Scan using
> ndalarmhistory_20000000_actionime_ix on ndalarmhistory_20000000
> ndalarmhistory (cost=0.00..229801.02 rows=1167 width=8) (actual
> time=20621.925..20621.925 rows=0 loops=1)"
> >> " Filter: ((action = 0) AND (ndalarm_id =
> 56::bigint))"
> [...]
> > > "Total runtime: 167307.212 ms"
>
> >> Wenn ich aber nun speziell in einer child tabelle suche:
> >>
> >> select ActionTime from NDAlarmHistory_20000000 where Action IN(0)
> AND
> >> NDAlarm_id IN ('56') order by actiontime desc limit 1
> >>
> >> "Limit (cost=0.00..3.45 rows=1 width=8) (actual time=0.020..0.020
> rows=0 loops=1)"
> >> " -> Index Scan using ndalarmhistory_20000000_action_ix on
> ndalarmhistory_20000000 (cost=0.00..4027.96 rows=1167 width=8) (actual
> time=0.018..0.018 rows=0 loops=1)"
> >> " Index Cond: ((action = 0) AND (ndalarm_id = 56::bigint))"
> >> "Total runtime: 0.042 ms"
> >>
> >> Extremer Unterschied!
> >>
> >> Warum wird auch oben nicht der Index benutzt, welches die untere
> Anfrage
> >> benutzt hat ? Vor der Partitionierung wurde der multi column index
> >> benutzt und meine Abfragen aus dem selben Volumen (43 Mio) schneller
> >> beantwortet.
>
> > 1. Deine Partitionierung paßt nicht zur Abfrage und ist damit hier
> nicht
> > hilfreich.
>
> Stimmt, das ist aber hier, glaube ich, nicht das Problem.

Meine Interpretation war eher so, daß er sich von der Partitionierung einen Performancegewinn erhoffte.

>
> Es ist klar, daß über alle Partitionen abgefragt wird.
> Aber warum wird bei jeder dieser Partitionen ein Index gescannt, der
> nur "actiontime" enthält? Das heißt doch, der gesamte Index muß
> durchsucht
> werden, nicht?
> Dabei gibt es einen Index, der besser ist.

Richtig. Ich bin mir nur nicht sicher, ob z.B. dieser Index schon bestand, als er die Abfrage laufen ließ, Oder so,
es ist jedenfalls schwer nachvollziehbar, siehe auch nächster Punkt.

Vielleicht nutzt er den 'falschen' Index, weil dieser kleiner ist, damit geringere Kosten hat. Oder die Statistiken waren
nicht aktuell.

>
> > 2. Dein Index heißt im Explain ndalarmhistory_20000000_actionime_ix,
> das
> > paßt nicht zu den definierten.
>
> Ja, das ist auffällig.

siehe oben ;-)

>
> > Ich versteh grad nicht den Sprung für actual time in Deinem Explain,
> > daher die Frage: Du kannst Copy&Paste - Fehler ausschließen?
>
> Ich sehe keinen Sprung...

"Limit (cost=10000000000.18..10000000052.84 rows=1 width=8) (actual time=167306.867..167306.867 rows=1 loops=1)"
" -> Result (cost=10000000000.18..10001542105.12 rows=29283 width=8) (actual time=167306.865..167306.865 rows=1 loops=1)"
" -> Merge Append (cost=10000000000.18..10001542105.12 rows=29283 width=8) (actual time=167306.864..167306.864 rows=1 loops=1)"
" Sort Key: public.ndalarmhistory.actiontime"
" -> Sort (cost=10000000000.01..10000000000.01 rows=1 width=8) (actual time=0.007..0.007 rows=0 loops=1)"
" Sort Key: public.ndalarmhistory.actiontime"
" Sort Method: quicksort Memory: 17kB"

von unten nach oben: 0.007..0.007 -> 167306.864..167306.864, bei rows=1 a bissl heftig...

>
> Leider kenne ich mich zu wenig mit Planer bei Partitionierung aus,
> um mehr sagen zu können.

Naja, er geht halt alle in Frage kommenden Partitionen durch (basierend auf constraint exclusion) und pappt die einzelnen
Resultate zusammen. Keine große Magie. Nur wenn die Partitionierung nicht zur Abfrage paßt, hat man außer einem höheren Aufwand
( komplexerer Plan, prüfen der einzelnen constraints, zusammenpappen, ...) keinen Nutzen.

Bei 'nur' 43 Millionen Rows würde ich noch nicht so schnell an Partitionierung denken, aber das ist Geschmackssache und
von der Anwendung abhängig.

Mit freundlichen Grüssen

Andreas Kretschmer
- Technik -

--
HINWEIS: Der internet24-Support arbeitet im Team -
bitte senden Sie daher immer die komplette Mailkommunikation mit.

-------------------------------------------------
internet24 GmbH Bayrische Str. 18 D-01069 Dresden
Fon : +49 (0)3 51 / 2 11 20 30
Fax : +49 (0)3 51 / 2 11 20 20
E-Mail : kretschmer(at)internet24(dot)de
Facebook: internet24gmbh
URL : www.internet24.de
Blog : blog.internet24.de

Geschäftsführer: Heiko Heerwagen
Registergericht: Amtsgericht Dresden HRB 12 899