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@postgresql.org
> [mailto:pgsql-performance-owner@postgresql.org] On Behalf Of Jim C.
> Nasby
> Sent: Thursday, February 09, 2006 1:34 PM
> To: Rafael Martinez Guerrero
> Cc: pgsql-performance@postgresql.org
> 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@postgresql.org so that your
> message can get through to the mailing list cleanly
>
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
