Content-Type: text/plain;
  charset="iso-8859-1"
From: Siva Kumar <tech@leatherlink.net>
To: Richard Huxton <dev@archonet.com>, pgsql-general@postgresql.org
Subject: Re: Query optimization
Date: Mon, 7 Oct 2002 16:58:58 +0530
User-Agent: KMail/1.4.1
References: <200210041347.55055.tech@leatherlink.net>
	<200210041756.35489.tech@leatherlink.net>
	<200210041429.51956.dev@archonet.com>
In-Reply-To: <200210041429.51956.dev@archonet.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Message-Id: <200210071658.58118.tech@leatherlink.net>

Thanks to Richard, Neil, Jochem and Antonis.

I went through the documentation on explain/analyse. Finally, decided to sp=
lit=20
up the query into two and to reduce the number of tables to get faster quer=
y.=20
In short, I have not solved the problem as presented (too lazy of me :-( ,=
=20
but opted to walk an easier path.=20

Thanks once again.

Best regards,

Siva Kumar=20


On Friday 04 Oct 2002 6:59 pm, Richard Huxton wrote:
> On Friday 04 Oct 2002 1:26 pm, Siva Kumar wrote:
> > Giving below the output of EXPLAIN ANALYSE. I could not make much sense
> > out of it, please help!
>
> Scary aren't they ;-)
>
> The important thing is you've got plenty of "Index Scan"s rather than Seq
>
> Scans. The other point is the final time:
> > Total runtime: 5.45 msec
>
> Now, since that's not what you're getting, I'd think Neil (see other repl=
y)
> is right and you need to look at issuing "SET geqo =3D off;" before the
> query.
>
> Postgresql has a genetic algorithm that kicks in on what it thinks is a
> very complex query, this can take a long time to analyse the options
> available but pays dividends on a big query. In your case you're only
> getting a few rows and so it takes longer to analyse than to get the
> results.
>
> The other thing that might work is rewriting the query with explicit JOINs
> - I think that should make it clear to Postgresql what order to do things
> in.
>
> - Richard Huxton