Re: Query runs in 335ms; function in 100,239ms : date problem?
От | Torsten Zühlsdorff |
---|---|
Тема | Re: Query runs in 335ms; function in 100,239ms : date problem? |
Дата | |
Msg-id | j44ht9$l20$1@dont-email.me обсуждение исходный текст |
Ответ на | Re: Query runs in 335ms; function in 100,239ms : date problem? (Rory Campbell-Lange <rory@campbell-lange.net>) |
Список | pgsql-general |
Rory Campbell-Lange schrieb: >>> Try to run it as a prepared query - I guess you'll get about the same run >>> time as with the function (i.e. over 100 seconds). >> The prepared query runs in almost exactly the same time as the function, >> but thanks for the suggestion. A very useful aspect of it is that I was >> able to get the EXPLAIN output which I guess gives a fairly good picture >> of the plan used for the function. >> >> The explain output is here: >> http://campbell-lange.net/media/files/explain.txt.html >> >> I'm inexperienced in reading EXPLAIN output, but it looks like the >> Nested Loop Semi Join at line 72 is running very slowly. > > I added in more filtering conditions to the clause at line 72 and the > prepared statement dropped in runtime to 24043.902 ms. Unfortunately the > function ran slower -- 47957.796 -- but even that is a 50% improvement. Also declare your function as STABLE. This can trigger an speed-increase. Greetings, Torsten -- http://www.dddbl.de - ein Datenbank-Layer, der die Arbeit mit 8 verschiedenen Datenbanksystemen abstrahiert, Queries von Applikationen trennt und automatisch die Query-Ergebnisse auswerten kann.
В списке pgsql-general по дате отправления: