[flymine-dev] Re: [release 3.1 webapp build]

[Richard Smith]

Yes, that is exactly the problem.  We have our max time set to
1000000000 but in your case I think that still wouldn't help.
This limit is imposed to prevent poorly constrained queries run
in a production environment from clogging up the database
server for too long.  When releasing the webapp it could be set
as high as you like.

A better option is to get the query to run a bit faster.  Have
you done an analyse on the restored dump?  We set our
default_statistics_target to 200.

Explanation if you haven't done much with postgres before:
Statistics are stored about each table (number of rows, etc)
and are used by the postgres query planner to choose sensible
queriy methods.  Whenever you restore a dump or significantly
alter the contents of the database you should run "analyse;" in
psql. 

default_statistics_target is a number between 1 and 1000 that
governs how precise the statistics are (default is 10).  High
numbers lead to slightly longer spent planning but should
result in more efficient queries.

So, you should try:
 > set default_statistics_target 200;
 > analyse;

The value is set only for a particular session, to see value:
 > show default_statistics_target;

It is better to set the in postgresql.conf and restart postgres.


Then try building the webapp again.  Hope this helps,
Richard.




AlexanderP@gmx.at wrote:

>here it is,
>
>ausgabe is the normal output
>errausgabe are the error messages...
>(attached)
>
>maybe it's only the Estimated time to run query greater than maximum...?
>
>from command:
>nice nohup ant -v build-production-webapp >ausgabe.dat 2>errausgabe.dat
></dev/null &
>
>kind regards,
>   alex
>
>
>
>