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 (minimal downtime) and there were some planner improvements. 4. what is "considerably more time" in absolute units? Filip 2011/12/27 MirrorX <mirrorx@xxxxxxxxx>: > 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 could > be the cause of this? > > information about the server-> > -CentOS 5.6 > -4-cores > -12GB ram > > > shared_buffers: 1 GB > temp_buffers = 100MB > work_mem : 30 MB > maintenance_mem: 512 MB > > database_size: 1,5 GB > archive_mode is ON > vacuum/analyze (vacuum_scale_factor 0.1, analyze 0.05) > > > this behaviour is not related with checkpoints on the database (as indicated > by the logs, i dont see this latency when a checkpoint occurs, i see it most > of the time) > > so my question is the following; what can cause the bind/parse phases to > take so much longer than the execute? if you need any more info the server i > ll be glad to provide it. thank you in advance for your advice > > -- > View this message in context: http://postgresql.1045698.n5.nabble.com/parse-bind-take-more-time-than-execute-tp5102940p5102940.html > Sent from the PostgreSQL - performance mailing list archive at Nabble.com. > > -- > Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
