Στις Friday 14 January 2011 22:06:56 ο/η Kevin Grittner έγραψε:
> Achilleas Mantzios <achill@matrix.gatewaynet.com> wrote:
>
> > The other form (NOT IN) is the problem (in the case of
> > postgresql-9.0.2). (in 8.3 both queries are fast)
>
> 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"?
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 "slower/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 test) 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, Linux 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 slow in 9.0.2 (over a variety of OS/HW).
> Is
> there something you're asking for as a change to the PostgreSQL
> product?
>
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
>
--
Achilleas Mantzios