ÎÏÎÏ Friday 14 January 2011 22:06:56 Î/Î Kevin Grittner ÎÎÏÎÏÎ: > Achilleas Mantzios <achill@xxxxxxxxxxxxxxxxxxxxx> 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 -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
