I looked at the estimates for the table access methods and they all looked ok, so I think the statistics are pretty up-to-date; there just aren't enough of them for the planner to do a good job. On Thu, Feb 09, 2006 at 01:44:22PM -0600, Dave Dutcher wrote: > First I'm wondering if the tables have been recently analyzed. If an > analyze has been run recently, then it is probably a good idea to look > at the statistics target. > > > -----Original Message----- > From: pgsql-performance-owner@xxxxxxxxxxxxxx > [mailto:pgsql-performance-owner@xxxxxxxxxxxxxx] On Behalf Of Jim C. > Nasby > Sent: Thursday, February 09, 2006 1:34 PM > To: Rafael Martinez Guerrero > Cc: pgsql-performance@xxxxxxxxxxxxxx > Subject: Re: [PERFORM] Help with optimizing a sql statement > > At least part of the problem is that it's way off on some of the row > estimates. I'd suggest upping the statisticss target on at least all of > the join columns to at least 100. (Note that it's doing a nested loop > thinking it will have only 2 rows but it actually has 22000 rows). > > On Thu, Feb 09, 2006 at 04:10:27PM +0100, Rafael Martinez Guerrero > wrote: > > Hello > > > > We are running an application via web that use a lot of time to > perform > > some operations. We are trying to find out if some of the sql > statements > > used are the reason of the slow speed. > > > > We have identified a sql that takes like 4-5000ms more than the second > > slowest sql in out test server. I hope that we will get some help to > try > > to optimize it. > > > > Thanks in advance for any help. > > > [Snip] > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your > message can get through to the mailing list cleanly > -- Jim C. Nasby, Sr. Engineering Consultant jnasby@xxxxxxxxxxxxx Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
