Skip site navigation (1) Skip section navigation (2)

Re: merge join killing performance

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: Matthew Wakeling <matthew(at)flymine(dot)org>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: merge join killing performance
Date: 2010-05-19 03:06:25
Message-ID: AANLkTinmK2qgKBQXpMZ0rDa66OsGH1MynmVwfkh1PZVy@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
On Tue, May 18, 2010 at 9:00 PM, Matthew Wakeling <matthew(at)flymine(dot)org> wrote:
> On Tue, 18 May 2010, Scott Marlowe wrote:
>>
>> Aggregate  (cost=902.41..902.42 rows=1 width=4)
>>  ->  Merge Join  (cost=869.97..902.40 rows=1 width=4)
>>        Merge Cond: (f.eid = ev.eid)
>>        ->  Index Scan using files_eid_idx on files f
>> (cost=0.00..157830.39 rows=3769434 width=8)
>
> Okay, that's weird. How is the cost of the merge join only 902, when the
> cost of one of the branches 157830, when there is no LIMIT?
>
> Are the statistics up to date?

Yep.  The explain analyze shows it being close enough it should guess
right (I think) We have default stats target set to 200 and the table
is regularly analyzed by autovac, which now has much smaller settings
for threshold and % than default to handle these big tables.

In response to

pgsql-performance by date

Next:From: Tom LaneDate: 2010-05-19 16:53:03
Subject: Re: merge join killing performance
Previous:From: Matthew WakelingDate: 2010-05-19 03:00:18
Subject: Re: merge join killing performance

pgsql-hackers by date

Next:From: Robert HaasDate: 2010-05-19 03:59:53
Subject: Re: Stefan's bug (was: max_standby_delay considered harmful)
Previous:From: Matthew WakelingDate: 2010-05-19 03:00:18
Subject: Re: merge join killing performance

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group