Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 6480B65025A for ; Tue, 22 Jul 2008 13:34:44 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 41756-02-8 for ; Tue, 22 Jul 2008 13:34:18 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by postgresql.org (Postfix) with ESMTP id C6B2165036A for ; Tue, 22 Jul 2008 13:19:58 -0300 (ADT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_gtKy/8RjhNyPZVQ30wUwjw)" Received: from [10.10.20.42] ([216.94.157.147]) by VL-MH-MR001.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug 3 2007; 32bit)) with ESMTPA id <0K4E002S6YDN4250@VL-MH-MR001.ip.videotron.ca> for pgsql-performance@postgresql.org; Tue, 22 Jul 2008 11:15:29 -0400 (EDT) Message-id: <4885F993.6020803@videotron.ca> Date: Tue, 22 Jul 2008 11:15:31 -0400 From: Patrick Vachon User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) To: Gregory Williamson Cc: pgsql-performance@postgresql.org Subject: Re: Difference between 8.1 & 8.3 References: <487E6A36.3010100@videotron.ca> <8B319E5A30FF4A48BE7EEAAF609DB233021F3037@COMAIL01.digitalglobe.com> In-reply-to: <8B319E5A30FF4A48BE7EEAAF609DB233021F3037@COMAIL01.digitalglobe.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.001 tagged_above=0 required=5 tests=HTML_MESSAGE=0.001 X-Spam-Level: X-Archive-Number: 200807/206 X-Sequence-Number: 30806 This is a multi-part message in MIME format. --Boundary_(ID_gtKy/8RjhNyPZVQ30wUwjw) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Hi, Finally found the problem. Turning off nested loops gave me much better performance on 8.3 than 8.1. The problem seems to come from postgresql miscalculation of the number of rows returned by nested loops. It is well described in that thread: http://archives.postgresql.org/pgsql-performance/2008-03/msg00371.php In my case, it was by a factor of 20000. Of course, I can't turn off nested loop in my database, it will impact performance on small tables too much... So there is no easy fix for that, it seems, beside playing with per-column statistics-gathering target maybe? Patrick Gregory Williamson wrote: > > Patrick Vachon wrote: > > > Hi guys, > > > > I've got a query that is running slower on 8.3 than on 8.1 (with > > equivalent server config), > > because the join ordering is not the same, at least that's my > guess... ;-) > > > > In 8.1.4, table A had 122880 pages, B 112690 pages and C 80600 pages. > > Now in 8.3.3, table A has only 77560 pages, B 69580 but C remains at > > 80600 pages. > > > > In 8.1 the tables were joined in that way (using explain analyse): > > C join A join B > > now in 8.3: > > B join A join C > > Beside that, the plan is very similar, but the indexes used are not the > > same. > > > > Could the number of disk pages of a table influence the > > order in which it is joined, even when it is scanned with an index? > > > > I'm pretty sure it is because of the reduced table sizes, > > since the server configuration is the same. > > > > Thoughts? > > 8.3 has fewer automatic casts to text types; perhaps you have indexes > which are not being used because of mismatched types ? Perhaps an > EXPLAIN ANALYZE from both, if possible, would clairfy. > > HTH, > > Greg Williamson > Senior DBA > DigitalGlobe > > Confidentiality Notice: This e-mail message, including any > attachments, is for the sole use of the intended recipient(s) and may > contain confidential and privileged information and must be protected > in accordance with those provisions. Any unauthorized review, use, > disclosure or distribution is prohibited. If you are not the intended > recipient, please contact the sender by reply e-mail and destroy all > copies of the original message. > > (My corporate masters made me say this.) > > ------------------------------------------------------------------------ > > No virus found in this incoming message. > Checked by AVG. > Version: 7.5.524 / Virus Database: 270.5.0/1558 - Release Date: 7/17/2008 9:56 AM > --Boundary_(ID_gtKy/8RjhNyPZVQ30wUwjw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi,

Finally found the problem.
Turning off nested loops gave me much better performance on 8.3 than 8.1.

The problem seems to come from postgresql miscalculation of the number of rows returned by nested loops.
It is well described in that thread:
http://archives.postgresql.org/pgsql-performance/2008-03/msg00371.php

In my case, it was by a factor of 20000.

Of course, I can't turn off nested loop in my database,
it will impact performance on small tables too much...
So there is no easy fix for that, it seems,
beside playing with per-column statistics-gathering target maybe?

Patrick

Gregory Williamson wrote:
RE: [PERFORM] Difference between 8.1 & 8.3

Patrick Vachon wrote:

> Hi guys,
>
> I've got a query that is running slower on 8.3 than on 8.1 (with
> equivalent server config),
> because the join ordering is not the same, at least that's my guess... ;-)
>
> In 8.1.4, table A had 122880 pages, B 112690 pages and C 80600 pages.
> Now in 8.3.3, table A has only 77560 pages, B 69580 but C remains at
> 80600 pages.
>
> In 8.1 the tables were joined in that way (using explain analyse):
> C join A join B
> now in 8.3:
> B join A join C
> Beside that, the plan is very similar, but the indexes used are not the
> same.
>
> Could the number of disk pages of a table influence the
> order in which it is joined, even when it is scanned with an index?
>
> I'm pretty sure it is because of the reduced table sizes,
> since the server configuration is the same.
>
> Thoughts?

8.3 has fewer automatic casts to text types; perhaps you have indexes which are not being used because of mismatched types ? Perhaps an EXPLAIN ANALYZE from both, if possible, would clairfy.

HTH,

Greg Williamson
Senior DBA
DigitalGlobe

Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information and must be protected in accordance with those provisions. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

(My corporate masters made me say this.)
 


No virus found in this incoming message.
Checked by AVG. 
Version: 7.5.524 / Virus Database: 270.5.0/1558 - Release Date: 7/17/2008 9:56 AM
--Boundary_(ID_gtKy/8RjhNyPZVQ30wUwjw)--