Re:

> -----Ursprüngliche Nachricht-----
> Von: Albe Laurenz [mailto:[email protected]]
> Gesendet: Donnerstag, 24. Mai 2012 09:54
> An: Andreas Kretschmer *EXTERN*; [email protected]
> Betreff: RE: [pgsql-de-allgemein]
> 
> Andreas Kretschmer schrieb:
> [schlechter Ausführungsplan für Abfrage auf partitionierter Tabelle]
> >>> 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...
> 
> Ah, ich sehe Deinen Irrtum.
> Der Sort bezieht sich nur auf die Elterntabelle:
> 
> Seq Scan on ndalarmhistory
>     (cost=10000000000.00..10000000000.00 rows=1 width=8) (actual
> time=0.002..0.002 rows=0 loops=1)
>     Filter: ((action = 0) AND (ndalarm_id = 56::bigint))
> 
> Weil diese Tabelle leer ist, ist ein Sequential Scan die beste
> Abfrageart.
> Die Resultate müssen dann allerdings sortiert werden.
> 
> Bei den anderen Partitionen muß nicht sortiert werden, weil dort ein
> Index Scan
> auf einen Index durchgeführt wird, der schon richtig sortiert ist.
> 
> Die tatsächliche Zeit des Merge Append ergibt sich so:
>      0.007 (ndalarmhistory)
>      0.136 (ndalarmhistory_0)
>    158.244 (ndalarmhistory_15000000)
>  20621.925 (ndalarmhistory_20000000)
>  19104.889 (ndalarmhistory_25000000)
>  33631.463 (ndalarmhistory_30000000)
>  22692.553 (ndalarmhistory_35000000)
>    199.805 (ndalarmhistory_40000000)
>  37295.011 (ndalarmhistory_5000000)
>  33602.814 (ndalarmhistory_10000000)
> ----------
> 167306.847
> 

*Patsch*

Ja, nun sehe auch ich meinen Irrtum, Danke für Deine Mühe!


Und ACK zum Rest Deiner Ausführungen.



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  : [email protected]
Facebook: internet24gmbh
URL     : www.internet24.de 
Blog    : blog.internet24.de 

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




-- 
Sent via pgsql-de-allgemein mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein