On Wednesday 10 June 2009 03:52:27 am Ed Leafe wrote: > On Jun 10, 2009, at 5:57 AM, johnf wrote: > > I have a some what complex form - 15 parent/child/grandchild > > relations. To > > clear my screen or reset the data I set the > > PrimaryBizobj.setWhereClause('1=0') and then do a Form.requery(). The > > requery() resets the form controls to blank values. The problem is > > one of > > performance. Sometimes the requery() takes a half second but many > > times it > > takes as much as 12 seconds. Waiting 12 seconds is a long time. > > Does anyone > > have a suggestion on improving the time. Or how I might determine > > the cause. > > If it's a performance problem with your backend, there's not much you > can do except perhaps use where clause that sets an indexed field to a > value that can't match. > > > -- Ed Leafe
I have considered the Postgres DB to be the cause of the difference in time. The cache might explain the difference. But checking the logs I find the actual cost in time for the entire process stays the same for each of the queries. That is to say when the screen clears in .5 of seconds vs 12 seconds the log reports the actual cost to retrieve the data to be the same. That said, I have not added indexes to improve performance yet. I normally wait until the tables are stable and I can review the postgres logs to determine where (and what) forced seq scans vs index scans. Creating indexes that are not used will only provide more overhead. Postgres also has the cluster command that will reorder an index (could be used on the PK). But I haven't had the chance to use it yet. And that might improve overall performance. Yet, I had not considered using a value for the where clause that does not exist in the primary key index. That might improve performance. The fact that the Postgres log reports the same actual cost for each of the requerys (.5 vs 12 seconds). Implies that the problem is else where. Any chance you have an idea where to look? -- John Fabiani _______________________________________________ Post Messages to: Dabo-users@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/200906100509.17773.jfabi...@yolo.com