MirrorX wrote:
-the table is this -
\d configurations
Table public.configurationcontext
One of my concerns was that you might actually be selecting against a
view rather than a table, and the above doesn't reassure me that
you're not. Why the difference between configurations and
thx for your reply :)
-the timings come from the log
-the table is this -
\d configurations
Table public.configurationcontext
Column | Type | Modifiers
---++---
id| numeric(18,0) |
MirrorX wrote:
default_statistics_target is set to (default) 100 and there no
special statistics per-column
in absolute units i can see the same query having similar stats to
these:
parse - 600 ms
bind - 300 ms
execute - 50 ms
How did you determine those timings?
the query
thx a lot for your answer :)
2) default_statistics_target is set to (default) 100 and there no special
statistics per-column
3) i will do that very soon
4) in absolute units i can see the same query having similar stats to these:
parse - 600 ms
bind - 300 ms
execute - 50 ms
the query mentioned
there are some performance issues on a server and by searching in the logs i
noticed that the phases of parse and bind take considerably more time than
execute for most of the queries. i guess that the right thing to do in this
case is to use functions or prepare statements but in any case, what
the version of postgres is 8.4.7 :)
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/parse-bind-take-more-time-than-execute-tp5102940p5102954.html
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.
--
Sent via pgsql-performance mailing list
hello.
1. planning time execute time, it can happen normally, for some
fast-executing queries, so it is not bad per se.
2. what are your statistics settings? they influence planning time. I
mean default_statistics_target and per-column SET STATISTICS?
3. upgrade to 8.4.10, it's quick upgrade
Hello
2011/12/27 MirrorX mirr...@gmail.com:
there are some performance issues on a server and by searching in the logs i
noticed that the phases of parse and bind take considerably more time than
execute for most of the queries. i guess that the right thing to do in this
case is to use
i am not using prepared statements for now :)
i just said that probably, if i do use them, i will get rid of that extra
time since the plan will be already 'decided' in advance
--
View this message in context:
