Re: performance change from 8.3.1 to later releases

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
Cc: Roger Ging <rging(at)musicreports(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: performance change from 8.3.1 to later releases
Date: 2010-04-21 03:47:01
Message-ID: 14045.1271821621@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> writes:
> On Tue, Apr 20, 2010 at 12:38 PM, Roger Ging <rging(at)musicreports(dot)com> wrote:
>> I have access to servers running 8.3.1, 8.3.8, 8.4.2 and 8.4.3. I have
>> noticed that on the 8.4.* versions, a lot of our code is either taking much
>> longer to complete, or never completing. I think I have isolated the
>> problem to queries using in(), not in() or not exists(). I've put together
>> a test case with one particular query that demonstrates the problem.

> We get a Seq Scan with a huge cost, and no hash agg or quick sort. Is
> the work_mem the same or similar?

It looks to me like it's not. The 8.4 plan is showing sorts spilling to
disk for amounts of data that the 8.3 plan is perfectly willing to hold
in memory. I'm also wondering if the 8.4 server is on comparable
hardware, because it seems to be only about half as fast for the plain
seqscan steps, which surely ought to be no worse than before.

regards, tom lane

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Greg Smith 2010-04-21 06:45:55 Re: Very high effective_cache_size == worse performance?
Previous Message Kevin Grittner 2010-04-20 21:57:11 Re: significant slow down with various LIMIT