Re: performance drop on 8.2.4, reverting to 8.1.4

From: "Steven Flatt" <steven(dot)flatt(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Steinar H(dot) Gunderson" <sgunderson(at)bigfoot(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: performance drop on 8.2.4, reverting to 8.1.4
Date: 2007-06-12 18:31:01
Message-ID: 357fa7590706121131t5adf3795ld006955d6f77e175@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Thanks Tom and Alvaro.

To follow up on this, I re-wrote and tweaked a number of queries (including
the one provided) to change "LEFT OUTER JOIN ... WHERE col IS NULL" clauses
to "WHERE col NOT IN (...)" clauses.

This has brought performance to an acceptable level on 8.2.

Thanks for your time,
Steve

On 6/7/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > Tom Lane escribió:
> >> I was hoping that the auto plan invalidation code in CVS HEAD would get
> >> it out of this problem, but it seems not to for the problem-as-given.
> >> The trouble is that it won't change plans until autovacuum analyzes the
> >> tables, and that won't happen until the transaction commits and sends
> >> off its I-inserted-lotsa-rows report to the stats collector.
>
> > I think there is something we can do about this -- drop the default
> > value for analyze threshold.
>
> Maybe worth doing, but it doesn't help for Steve's example.
>
> regards, tom lane
>

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2007-06-12 18:42:57 Re: test / live environment, major performance difference
Previous Message Vivek Khera 2007-06-12 18:24:59 Re: Best use of second controller with faster disks?