From: Achilleas Mantzios <achill@matrix.gatewaynet.com>
Organization: Dynacom Tankers Mgmt
To: pgsql-admin@postgresql.org
Subject: Re: Postgresql 9.0.2 explain analyze very slow (10x),
	compared to actual query time
Date: Fri, 14 Jan 2011 22:32:15 +0200
User-Agent: KMail/1.9.7
References: <201101111753.22602.achill@matrix.gatewaynet.com>
	<201101141752.34986.achill@matrix.gatewaynet.com>
	<4D30588002000025000395E7@gw.wicourts.gov>
In-Reply-To: <4D30588002000025000395E7@gw.wicourts.gov>
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <201101142232.15791.achill@matrix.gatewaynet.com>
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable

=CE=A3=CF=84=CE=B9=CF=82 Friday 14 January 2011 22:06:56 =CE=BF/=CE=B7 Kevi=
n Grittner =CE=AD=CE=B3=CF=81=CE=B1=CF=88=CE=B5:
> Achilleas Mantzios <achill@matrix.gatewaynet.com> wrote:
> =20
> > The other form (NOT IN) is the problem (in the case of
> > postgresql-9.0.2).  (in 8.3 both queries are fast)
> =20
> So running EXPLAIN ANALYZE for this plan on the 9.0 version checks
> the time in more places than the 8.3 version.  For a plan that's an
> order of magnitude slower than the plan used by the recommended
> version of the query.  Have you looked at what options you have for
> getting a faster clock reading on this "slower/older machine"?=20

Kevin, momentarily, lets forget about the slow EXPLAIN ANALYZE part.
Also lets forget about the fact that the LINUX_TEST running 9.0.2 is a "slo=
wer/older" machine.
(its definetely "faster/newer" than FBSD_DEV)
The reason i got into trouble setting a new linux box (the 4th box in the t=
est) just for this problem was to show that
the thing is not FreeBSD related.

We have clearly a query that runs fine in two boxes (FreeBSD - FBSD_DEV, Li=
nux LINUX_PROD) running PostgreSQL 8.3.13
but runs a lot slower in two other boxes (FreeBSD - FBSD_TEST, Linux LINUX_=
TEST) running PostgreSQL 9.0.2

It is true that the thread might have to move over to pgsql-performance, if=
 it there was no 8.3.13 involved,
in other words if we had only the old "EXISTS" vs "IN" situation.

Here we have smth which runs fast in 8.3.13 (over a variety of OS/HW) but s=
low in 9.0.2 (over a variety of OS/HW).

> Is=20
> there something you're asking for as a change to the PostgreSQL
> product?
> =20
What i am asking is ways to understand what is going on, and what to expect=
 when i will have to actually perform the production
upgrade to 9.0.2
> -Kevin
>=20


=2D-=20
Achilleas Mantzios